I'm a dev transitioning from EE focusing primarily on full-stack web development! I've worked with JS/TS, golang, Flutter, Scala, and some devops tools. I'd be very interested in career opportunities.
Whoa! writing my question here I realize that the logic you proposed is perfect! The error is in my frontend trying to revalidate the token several times. Obviously, if the token has already been revalidated, there would be no need to send new requests.
My problem is in an interceptor that I defined in axios to make requests, that every request if the token was invalid I am sending several refresh tokens.
Anyway, thanks for your attention and sorry for the English, I'm Brazilian lol.
Basically my interceptor is taking the same refresh token and sending it several times. In case only one request will be validated, the others will be ignored since the previous refresh token will have been removed from the redis.
I'm a dev transitioning from EE focusing primarily on full-stack web development! I've worked with JS/TS, golang, Flutter, Scala, and some devops tools. I'd be very interested in career opportunities.
No worries! I think it's awesome you're doing this in a second language.
I'm glad you were able to sort your issue out from the client side!
There is at least one potential issue I am aware of with my application.
If you sign in repeatedly (without signing out), the redis store will keep creating refresh tokens. So it is possible you would add tons of entries in Redis!
From the "good guy" developer's perspective, you will define your client-side code to avoid this. But it would be good to have a safety mechanism or some logic to prevent this on the server.
Maybe sending a cookie with the client's ID (an ID that is unique per device/browser) in the authentication responses (sign in/sign up), and then checking this on incoming requests would be helpful, but I haven't thought this through yet.
I would be interested in seeing how services like Auth0 handle this in their API.
Best of luck with your app!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for communicating!
I haven't considered this scenario.
I don't understand from your message what resource is responding with the 401.
Are you saying that you get a 401 status when attempting to delete a resource, but that the resource is deleting anyway?
Whoa! writing my question here I realize that the logic you proposed is perfect! The error is in my frontend trying to revalidate the token several times. Obviously, if the token has already been revalidated, there would be no need to send new requests.
My problem is in an interceptor that I defined in axios to make requests, that every request if the token was invalid I am sending several refresh tokens.
Anyway, thanks for your attention and sorry for the English, I'm Brazilian lol.
Basically my interceptor is taking the same refresh token and sending it several times. In case only one request will be validated, the others will be ignored since the previous refresh token will have been removed from the redis.
This was the problem. Thank you very much!
No worries! I think it's awesome you're doing this in a second language.
I'm glad you were able to sort your issue out from the client side!
There is at least one potential issue I am aware of with my application.
If you sign in repeatedly (without signing out), the redis store will keep creating refresh tokens. So it is possible you would add tons of entries in Redis!
From the "good guy" developer's perspective, you will define your client-side code to avoid this. But it would be good to have a safety mechanism or some logic to prevent this on the server.
Maybe sending a cookie with the client's ID (an ID that is unique per device/browser) in the authentication responses (sign in/sign up), and then checking this on incoming requests would be helpful, but I haven't thought this through yet.
I would be interested in seeing how services like Auth0 handle this in their API.
Best of luck with your app!