Skip to content
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

authIdentity.get() is not always the information obtained from the signin URL #23

Open
wu-lee opened this issue Nov 12, 2015 · 0 comments

Comments

@wu-lee
Copy link

wu-lee commented Nov 12, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant