Library not handling 401 error response?

[michaelbazos]

Hi,

I was reading the part related to interceptors in the documentation, which states:

Since 3.1 the library uses a default HttpInterceptor that takes care about transmitting the access_token to the resource server and about error handling for security related errors (HTTP status codes 401 and 403) received from the resource server.

Reading at the library code version 4+ (4.0.2 to be precise), I can see that the Authorization header is sent, providing that the flag sendAccessToken is set, however I don't see any handling of the "401 Unauthorized" http response.

Can anyone shed some light? Maybe I'm missing something?

[jeroenheijmans]

The library has no logic at all for retry policies, or for redirecting on 401/403 (or anything related). The only interceptor provided by the lib itself is one to append the Authorization: Bearer ... header to requests made to the Resource (API) Server.

You can also check my earlier issue, #414, about the same topic. Perhaps this issue is even a duplicate?

In the end, it would probably make sense to have the application decide how to handle 401/403 errors though, given that there's many different possible options (do nothing, show a dialog, redirect users to log in, only try silent refresh, etc.).

[michaelbazos]

Thanks for looking into it @jeroenheijmans

I noticed #414, it is related, but different in the sense that it is more about hooking custom logic, like retries, on error responses.

I went to open this question-issue as I was confused by the statement that the library does handle 401 and 403.

Not that it is hard to write an interceptor in the application itself, but I think it makes sense that the library redirects by default to login on 401 errors, and that it allows this behavior to be overridden.

[jeroenheijmans]

Hah, good points. I clarified the other issue as well.

The retries mentioned there are secondary, the actual important thing is logging the user in (silently, if possible). Same as your intention, I still think? It's just that you seem to prefer what I called "Option 4", making the login upon 401/403 (and retry if the login was done silently), whereas I think it's an application concern and thus lean to "Option 1".

In any case, I would agree that the current documentation you quoted is not appropriate. Possibly the original author intended to suggest that 401s/403s are "prevented" by the default interceptor provided by the library, which is the case.

So in any case, I'm all for changing that bit of documentation to match current library behavior.

I'm not so sure if I'm fore "Option 4" / having the library redirec on 401s (certainly not by default), since those flows can vary greatly between applications.

[michaelbazos]

I see. So the 401 / 403 that would occur because of the lack of the Authorization header are handled, not the 401 / 403 in general 🙂

[jeroenheijmans]

I think so, yeah. AFAIK there's no feature in the library to handle 401/403 when the bearer token is already being sent.

[jeroenheijmans]

Think the questions in this thread got answered, and since related issues and PRs have been resolved as well I'm going to close this issue.

Let us know if the issue should be re-opened (and what open issue still remains)!