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?
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.
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)?
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.
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?
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.
Great. That’s just what I was envisioning. I can definitely try to whip something simple up.
Awesome, let us know if you need any help!
hmmm … going to tickle this now that I am working on auth, did you have a chance to look at any of this?
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?
We have not looked at it. Would love it if you had a look
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
FooBar@gMail.com as your email in settings will not match
firstname.lastname@example.org as it is returned by Google authentication, erroneously triggering a new account setup dialog.
Per the official spec, email addresses are in fact case sensitive – for the name, not the domain. You can check Wikipedia to verify.
I mistook common practice for authority. Thanks for the correction.
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.
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.
Also, I have an unrelated gift for you, I improved the name splitting heuristic:
I was about to ask for that!
This looks like a good start to me, stuff to think about while working on this:
- How will plugins add options there?
- How do you disconnect?
- Do we need to get people to approve a change via email?
- What logging should we have?