-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to deal with refresh tokens that are expired? #8
Comments
Like a callback? Not really but feel free to send a PR! |
That was a fast response :-D Thanks! I just saw that it's probably easiest to just add a catch statement to the |
@florianmartens additionally you could set up your backend so that it also refreshes and returns refresh tokens every time you refresh your access token. This way a user is logged in for as long as they use your (web) app every now and then (depending on your refresh token expiration) |
@mvanroon It still leaves a problem that the refresh token will expire at some point in the future, and the call to the backend will throw an exception that will not be handled by the |
That’s a good thing right? It will cause the axios call to throw an error which you can catch. If the status code is 401 you navigate the user to the login page |
@mvanroon I get an error in the console even though I chained a |
When I create my refresh function llike this:
Then it sort of works, but the
I would expect to get an authorization error and redirect the user to the login page. Is there a way to return the refresh token endpoint's response from the interceptor, and handle it as if I don't have a token in the client. I am unauthorized, it should be handled in the same manner. |
Thanks for the detailed response. I suppose we should re-throw the exception received from the refresh call and alter the message (prefixing it with ‘Unable to refresh token:’) instead of throwing an entirely new exception. This should be the general idea imo:
An alternative would be to allow one to specify a callback that would be called (
Or both :-) |
@mvanroon The problem is that the exception thrown when I try to fetch something from the api does not have The alternative solution would probably work, but I find it sort of icky to inject my router into my rest api client initialization, and not informing the caller of what happened to the request. For now, I handle all the other statuses first, and than in the end, I just assume that the error was an authorization error.
Also icky, but the least icky option, I think. I with I could just get an exception with the 401 response. |
I am dealing with the same problem right now. This is what my requestRefresh function looked like at first:
The problem was that when the backend returned a 401 because the refresh token expired, the following exception came up and my application didn't load properly:
Now I have changed my code to this:
This looks better now. The logic of my "logout" function is executed and my application loads as I expect it to. However, the following exception still appears in the console:
The exception occurs because I do not make a return in case of an error, since there is nothing I can return. Returning "null" doesn't work either. I think the code could be improved to also accept a "null" and handle it accordingly. |
Thanks for creating this cool library!
I was wondering how to deal with expired refresh tokens? Currently, there seems to be no way to handle this. Is it possible to specify a force-logout URL in case the refresh fails with a 401 or 403?
Thanks!
The text was updated successfully, but these errors were encountered: