Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Should we invoke onlogin() in response to request() if the selected identity matches loggedInUser? #3332

callahad opened this Issue May 1, 2013 · 5 comments


None yet
3 participants

callahad commented May 1, 2013

(via StackOverflow)

The Scene

  1. You are currently logged into example.com as foo@mockmyid.com
  2. You refresh example.com.
  3. When the page loads, loggedInUser is already set correctly, "foo@mockmyid.com"
  4. onmatch fires, followed by onready
  5. You are now looking at your logged-in view of example.com

The Actions

  1. You click a link that triggers id.request().
  2. In the picker, you choose foo@mockmyid.com and click "next."

The Result

Your selected identity matches the current page state. Which of these should happen?

  1. Nothing
  2. The onmatch callback fires.
  3. The onlogin callback fires.
  4. Something else

6a68 commented May 1, 2013

@callahad I'm not sure you should be able to click a link, when logged in, that triggers id.request(). What's an example?


callahad commented May 1, 2013

@6a68 So you'd vote for "undefined behavior" here? The one non-weird case I can think of is a "Switch Accounts" button, which is apparently very common in Drupal sites.


6a68 commented May 1, 2013

@callahad 'Switch Accounts', to me, sounds like "log out, then log in as another user." If I'm understanding correctly, the flow you're describing comes down to:

  1. you log in as "foo@mockmyid.com"
  2. you click 'Switch Accounts'
  3. you see the picker and...choose "foo@mockmyid.com" again (?)

To me, this feels equivalent to a website always displaying the login button. I think the experience is going to be odd, no matter what, because it's odd to show a login button when you're already logged in--it tells the user they actually aren't logged in.

TL;DR: I'd vote for firing onmatch() again, because the login button should always behave the same way.

In my opinion no callbacks should be called if loggedInUser equal to Persona's state.

Visitor entered Persona's credentials, send assertion code to backend and successfully confirm that he has that email address. So, from server I can response with that email and store it as a session variable. After that I can handle that response with "onlogin" callback.

When page has been reloaded it should be repopulated with email address from server response (or by calling ajax to get email of logged in user). Also, as email stored in session I already know that user logged in and can handle his requests keeping this fact in mind.


callahad commented Oct 31, 2014

Hi! To help us better focus, I'm "closing" all issues that have been open for more than six months. These have been tagged "cleanup-2014" so that we can go back and review them in the future.

For more information, check out this thread: http://thread.gmane.org/gmane.comp.mozilla.identity.devel/7394

If you believe this bug is still a major issue for you, please comment, submit a pull request, or discuss it on our mailing list: https://lists.mozilla.org/listinfo/dev-identity

Sorry for GitHub notification spam!

@callahad callahad closed this Oct 31, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment