For extension @loopback/authentication-jwt there are two suggestions to improve:
1) The id should be UUID and
2) Email of the user should be unique
For UUID:
UUID values are unique across tables, databases, and even servers that allow you to merge rows from different databases or distribute databases across servers. UUID values do not expose the information about your data so they are safer to use.
In current scenario its a number
Form email uniqueness:
Preventing user from registering multiple account from single email.
In current scenario, there may me duplicate users with same email can signup or register.
For unique email, you can use the database to ensure the uniqueness. See shopping example that uses a unique constraint. How does this fit with your train of thought?
@dougal83: I Yes you are right. and do you think this should benefit users who are using this extension directly.
But Idea here is to implement(actually I have implemented this) that thought in to extension @loopback/authentication-jwt.
@madaky Are you checking uniqueness in code? I think you've got to be wary of race conditions(unlikely but possible) but IMO ultimately database should be constrained so you would need to contend with the decoupled data connectors.
For UUID idea, I do have a personal preference to expose non db keys (and link to key) for something like one time tokens (e.g. reset password token) but that being said if the api is secured robustly it should not be considered a security concern. It should IMO be a concern for efficiency with scale with uuids being used where efficiency allows. Thanks for starting the conversation, it's making me reconsider my approach. 馃憤
PR #5544.
Thanks @dhmlau @jannyHou @bajtos @raymondfeng @dougal83 : for the help.
Most helpful comment
@madaky Are you checking uniqueness in code? I think you've got to be wary of race conditions(unlikely but possible) but IMO ultimately database should be constrained so you would need to contend with the decoupled data connectors.
For UUID idea, I do have a personal preference to expose non db keys (and link to key) for something like one time tokens (e.g. reset password token) but that being said if the api is secured robustly it should not be considered a security concern. It should IMO be a concern for efficiency with scale with uuids being used where efficiency allows. Thanks for starting the conversation, it's making me reconsider my approach. 馃憤