Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
xprnio3756yOr change your JWT secret, so that the client's key just wouldn't work, regardless of the user ID inside it.
-
BashouT5816y@ScriptCoded Most places prefer guids to IDs normally to prevent sequence based attacks anyway, I'd say unless you have a good reason to use numerical IDs I would go with a guid
-
@BashouT Yeah and we will switch to it before launching (it's easier in development). Though I wanted to know anyways
-
KDSBest7756yNormally jwt token have an expire time and of course like @ScriptCoded said a build server that switches secrets on release is not a bad idea.
Related Rants
So this is kind of an odd scenario, but bare with me. My client has been issued a JWT token. After having received and stored it, I completely reset the database, and so also emptied the users table. Note that we're using MySQL with auto incrementing ID, whose counter has been reset. The user ID is stored in the JWT, so now the JWT isn't referencing an existing user anymore, so the client will get a 401. The problem arises when a new user registers and is inserted in the new database. That user will get ID 1, and so the old token for the other user will suddenly be valid for another user. I know it's an odd case, but is this a flaw in JWT? I guess an easy solution would be to use random ID's, but I'm still wondering.
question
jwt
sql