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
This is a hard issue to describe in a way you can replicate, without sending you my entire application. If I get time later I may attempt to construct a simple example. Nevertheless, for now, this is what I know.
The symptom: authIdentity.get() sometimes does not return user identity information obtained from the signin URL configured via dgAuthServiceProvider.setConfig(), as I believe it is meant to. Instead it contains the response to another URL, which varies depending on the circumstance.
This manifests in my app as being shown as logged in by no-one, or some nonsensical user depending on the URL data we actually get. In my app this is repeatable by logging out (which calls the dgAuthService.signout() method), reloading the browser page and then logging in again.
The cause. Inspecting the code and debugging, what seems to be happening is that the signin url is never actually requested, because within the authRequests.signin() function, there is a cached request to another URL obtained at line 1172. The response from this is what gets set into the authIdentity object.
The cached request is made by the application following an event broadcast by the successful callback bound to dgAuthServiceProvider.callbacks.login. It is intended to update my application's data structures. Apparently it may get invoked before authRequsts.signin() does.
In other words, what I think is happening is that angular-auth-digest is caching the failed API calls meant to update my application's data structures, and then when the user has entered their login, it replays them instead of calling the configured signin URL, and the authIdentity object is set by the first result to come back.
The sequence of events I see in my console log output is as follows:
authRequests.signin() called: (angular-digest-auth.js line 1168)
This gets my signin URL "/api/user" -> 401 Unauthorized
Login dialog opened
Credentials entered, dialog submitted
my application attempts to update its data from "/api/foo"-> 401 Unauthorized
authRequests.signin() called: (angular-digest-auth.js line 1168)
request to "/api/foo" is resent -> 200 OK, returns the response object FOO
loggedIn action sets authIdentity to FOO (angular-digest-auth.js line 230)
loggedIn action also sets credentials with { username="Controllis", password="Controllis" (angular-digest-auth.js line 235)
loggedIn action calls login.successful callback with FOO (angular-digest-auth.js line 240)
Promise returned for request to "/api/foo" is resolved successfully and the callback invoked in my application.
The docs mention authIdentity but not authService.getCredentials(), thus I assume authService.getCredentials() is internal. However it does seem to be more reliable, in the current scheme, so I am using this as an alternative to authIdentity.get() for now. More explanation of authIdentity and its purpose would be welcome!
Thanks.
The text was updated successfully, but these errors were encountered:
This is a hard issue to describe in a way you can replicate, without sending you my entire application. If I get time later I may attempt to construct a simple example. Nevertheless, for now, this is what I know.
The symptom: authIdentity.get() sometimes does not return user identity information obtained from the
signin
URL configured viadgAuthServiceProvider.setConfig()
, as I believe it is meant to. Instead it contains the response to another URL, which varies depending on the circumstance.This manifests in my app as being shown as logged in by no-one, or some nonsensical user depending on the URL data we actually get. In my app this is repeatable by logging out (which calls the
dgAuthService.signout()
method), reloading the browser page and then logging in again.The cause. Inspecting the code and debugging, what seems to be happening is that the
signin
url is never actually requested, because within theauthRequests.signin()
function, there is a cached request to another URL obtained at line 1172. The response from this is what gets set into theauthIdentity
object.The cached request is made by the application following an event broadcast by the
successful
callback bound todgAuthServiceProvider.callbacks.login
. It is intended to update my application's data structures. Apparently it may get invoked beforeauthRequsts.signin()
does.In other words, what I think is happening is that angular-auth-digest is caching the failed API calls meant to update my application's data structures, and then when the user has entered their login, it replays them instead of calling the configured
signin
URL, and the authIdentity object is set by the first result to come back.The sequence of events I see in my console log output is as follows:
authRequests.signin()
called: (angular-digest-auth.js line 1168)authRequests.signin()
called: (angular-digest-auth.js line 1168)loggedIn
action sets authIdentity to FOO (angular-digest-auth.js line 230)loggedIn
action also sets credentials with { username="Controllis", password="Controllis" (angular-digest-auth.js line 235)loggedIn
action calls login.successful callback with FOO (angular-digest-auth.js line 240)The docs mention
authIdentity
but notauthService.getCredentials()
, thus I assumeauthService.getCredentials()
is internal. However it does seem to be more reliable, in the current scheme, so I am using this as an alternative toauthIdentity.get()
for now. More explanation ofauthIdentity
and its purpose would be welcome!Thanks.
The text was updated successfully, but these errors were encountered: