You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 30, 2021. It is now read-only.
Hey, is there any particular reason to have two similar interceptors in core/services and in users/config.
IIRC the first one is the most recent and maybe people forgot to delete the latter or merge in the same file possible changes (only one I can think of is Authentication.user = null; which is missing in the first one).
The text was updated successfully, but these errors were encountered:
I think you're absolutely right. We don't need both, and the older one was probably overlooked when the authInterceptor service was implemented. I don't see anything that would prevent us from removing the $http provider config from the User's module; the authInterceptor service is a much better implementation.
We do need to add Authentication.user = null; to the service before this line, authInterceptor service 401, and we should be good. This will clear the user out of the browser, so that the lack of authentication is properly represented.
Related, but not a factor for this issue: We need to address the issue of a 403 status in the interceptor, caused by a request from an unauthenticated user. I think the ACL's will need to be updated to return 401 in these cases.
Hey, is there any particular reason to have two similar interceptors in core/services and in users/config.
IIRC the first one is the most recent and maybe people forgot to delete the latter or merge in the same file possible changes (only one I can think of is
Authentication.user = null;
which is missing in the first one).The text was updated successfully, but these errors were encountered: