Skip to content
This repository has been archived by the owner on May 10, 2019. It is now read-only.

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

Closed
callahad opened this issue May 1, 2013 · 5 comments

Comments

@callahad
Copy link
Contributor

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
@jaredhirsch
Copy link
Member

@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
Copy link
Contributor Author

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.

@jaredhirsch
Copy link
Member

@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.

@cotton-more
Copy link

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
Copy link
Contributor Author

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!

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

No branches or pull requests

3 participants