Allow authentication via multiple services on one account

(David Celis) #1

If you have all six authentication services enabled as well as username/password and you’re a fairly forgetful person (like me), it’s possible you’ll repeatedly forget what service you used to authenticate with a Discourse installation. It would be nice if, after my initial signup, I could go into my preferences and create more *_user_info associations with my account so that I can choose any old service to login to my existing account.

Why use Discourse over Linkedin, Google, or Facebook Groups?
(Jeff Atwood) #2

Any service should already work to log you in provided it maps to the same validated e-mail address. In that sense you don’t need to remember, you just have to use a login mechanism that has the same email address as we have on record. Have you tried it?

But only one service plus the intrinsic traditional forum username/password will be permanently associated with the account.

(David Celis) #3

Ah, no. I hadn’t thought to try that; the services I tried were registered under different email addresses. Is this something that should already work (i.e. did you ask me to try it so that I could see for myself, or out of mutual curiosity)?

(Sam Saffron) #4

Almost true, there is currently no way to associate with Twitter or Github once you have an account.

I would like this sorted PR welcome.

(David Celis) #5

To be clear, @sam, a PR to allow association via different accounts? Or a PR to somehow allow login with Twitter/GitHub once you have an account?

(Sam Saffron) #6

Any/all of this would be fine. I would keep it simple though first. Just have buttons to allow a user to add a “missing” auth method in edit prefs.

(David Celis) #7

Great. That’s just what I was envisioning. I can definitely try to whip something simple up.

(Sam Saffron) #8

Awesome, let us know if you need any help!

(Sam Saffron) #9

hmmm … going to tickle this now that I am working on auth, did you have a chance to look at any of this?

(David Celis) #10

I didn’t, sorry! I got hung up on a lot of other things and kind of forgot about this. I’d still be willing to take a look at some point if you haven’t already?

(Sam Saffron) #11

We have not looked at it. Would love it if you had a look :slight_smile:

(Roy Ivy III) #12

For a long while, I’ve thought this was still a work in progress, not working as described, even for just one alternate login method. But I realize now that I’ve been running into a case matching bug.

Email addresses should be case insensitive. But, if an authentication service returns an email address which differs only in case from the email address saved in user settings, it is not seen as a match.

For example, having as your email in settings will not match as it is returned by Google authentication, erroneously triggering a new account setup dialog.

(Jeff Atwood) #13

Per the official spec, email addresses are in fact case sensitive – for the name, not the domain. You can check Wikipedia to verify.

(Roy Ivy III) #14

I mistook common practice for authority. Thanks for the correction.

(Stefano Bernardi) #15

Any updates on this? I have some code used for other apps that does exactly this. If it hasn’t been worked on, I’m happy to figure it out and send a PR.

(Sam Saffron) #16

No one is working on this at the moment, mind sending a quick UI mock before getting started. Once that is done totally happy for you to work on this, would be awesome.

(Sam Saffron) #17

Also, I have an unrelated gift for you, I improved the name splitting heuristic:

(Stefano Bernardi) #18

I was about to ask for that!


(Stefano Bernardi) #19

Something like this (didn’t bother masking my email as it’s public anyways)

(Sam Saffron) #20

This looks like a good start to me, stuff to think about while working on this:

  1. How will plugins add options there?
  2. How do you disconnect?
  3. Do we need to get people to approve a change via email?
  4. What logging should we have?