-
Notifications
You must be signed in to change notification settings - Fork 694
Support for refresh and retry upon 401/403 errors in interceptor #414
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
Comments
Based on the links @jeroenheijmans shared and on what this package offers I came into a solution for retrying requests that have failed with 401 error. I had to create an additional interceptor for errors but I'm not that happy to have to manually set the authentication token by myself again, since that feature is already present in the
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There's good documentation on interceptors, and I'm trying to combine it with this approach on Stack Overflow for retries upon 401/403 errors. However, I think some extension points are missing.
The
OAuthResourceServerErrorHandler
type isn't "strong" enough for retries, because thehandleError
signature doesn't include access to thereq
(request) ornext
(next interceptor) for implementing the retry.I can of course write my own
HttpInterceptor
that mixes theDefaultOAuthInterceptor
with the approach from the SO post. But I don't like that approach too much, because then I effectively fork theDefaultOAuthInterceptor
, missing out on any bugfixes in future versions.I'm happy to create a PR for improving this. But then (a) I would need to know that this would be something that'll be potentially accepted, and (b) would like some guidance on the direction of the approach, because I can see these major approaches:
DefaultOAuthInterceptor
, that allow implementing a retry strategy.DefaultOAuthInterceptor
and extract parts of theintercept
function into seperate types, so that they can be reused.intercept
method a bit so that a subclass can be created that uses the super class but extends its features.HttpInterceptor
in the library itself that has all the Default interceptor's features plus also a retry+login strategy built in.I lean towards the first option myself, because it's more in line with how the other extension points in this library work.
Edit, footnote: in #429 I was attended to the fact that this story seems to focus mostly on retries. However, it is in fact more about having to log in upon 401/403 (and I think that if that can be done with a silent refresh, a retry is a good additional bonus - also, whether you want a hard login redirection in addition to an attempt at silent refresh, is an application concern imho).
The text was updated successfully, but these errors were encountered: