Docs incorrectly state setting `sendAccessToken` enables library handling of 401/403 HTTP status codes

[danielsharvey]

Describe the issue The documentation indicates that the use of the sendAccessToken setting enables an interceptor including: "error handling for security related errors (HTTP status codes 401 and 403) received from the resource server".

See:

• https://manfredsteyer.github.io/angular-oauth2-oidc/docs/additional-documentation/working-with-httpinterceptors.html
• https://github.com/manfredsteyer/angular-oauth2-oidc/blob/8d152c20ea1dab006a7eca02898260254872e79b/docs-src/interceptors.md?plain=1#L3

I can't see this in behaviour or in the code i.e. the default unless a custom handler is provided is OAuthNoopResourceServerErrorHandler; see here.

Stackblitz example N/A

To Reproduce N/A

Expected behavior The documentation indicates that setting sendAccessToken to true enables handling of 401 and 403 HTTP status codes.

Desktop (please complete the following information): N/A

Additional context N/A

[danielsharvey]

I'm happy to submit a PR but wanted to understand what was intended and/or if I'd missed something.

[jeroenheijmans]

I think the documentation is incorrect, and should not say:

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.

But instead say

Since 3.1 the library uses HttpInterceptors. A default HttpInterceptor takes care about transmitting the access_token to the resource server (if configured). Applications can also use their own custom interceptors for handling of security related errors (HTTP status codes 401 and 403) received from the resource server.

In #429 someone noticed similarly that the docs were not entirely correct, and #414 also has som emore info on how (I personally think that) it's an application concern and needs custom application logic to determine what happens on 401/403 errors.

Hope you don't mind if I edit your question title to indicate the docs need improvement? If not let me know and we'll revert and I'll open a separate issue for it.

[danielsharvey]

This sounds good, thank you.

[craigbroadman]

If I'm reading this correctly, the docs are still wrong as the PR hasn't been completed and therefore we have to create our own interceptor to handle 401/403 status codes.

If correct, does anyone have a simple example they could share?