-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Possible Logout Issue #46
Comments
Thanks so much for the PR. Do you think that these tests provide adequate coverage for this issue? |
Looks good to me! As far as the server-side of things go, the more I think about it, the more I agree that error responses should still be rotating tokens (if configured). So I can't imagine anything needs to change in devise_token_auth unless you feel otherwise. Feel free to close unless you disagree. Thanks @lynndylanhurley ! |
I totally agree. Good work! 👍 |
Hey @lynndylanhurley -
Ran into an issue with ng-token-auth (0.0.23-beta2) / devise-token-auth (0.1.29) sometimes resulting in 401 unauthorized while hitting API routes while using changing tokens.
This seems to happen after a request errors, resulting in a non 200 OK response from the server. This only happens when a token has been re-generated in the
after_action
callback in the devise_token_authset_user_by_token.rb
concern.The $httpInterceptor in ng-token-auth has appropriate
request
andresponse
handlers, but noresponseError
handler. So, when an errored request (that is also updating the token) has its response hit the client, ng-token-auth never callssetAuthHeaders
with the updated headers.I'm not sure what's the most appropriate fix in this case. devise_token_auth could only update tokens if the response was successful, but I'm not sure that's the right thing to do or not. I'm leaning towards ng-token-auth essentially duplicating the
response
handler forresponseError
so it could be more agnostic. Thoughts?The text was updated successfully, but these errors were encountered: