Is it possible to use Discourse with SSO and email addresses which are not unique?
That means users have multiple accounts with different usernames but same email addresses.
No, emails are unique identifiers for users in Discourse and this is fundamental to all identity in the system.
1 Like
A work around for many people is to use +addressing, like user+joe@gmail.com, user+pat@gmail.com, and so on. O all email providers support that, but most do.
2 Likes
@pfaffman how exactly is that going to help them there? By disambiguating? That is true, when you have
user@example.com
you could change it to
user+secondary@example.com1
It’s often useful to have multiple accounts, and using +addressing lets you do that without creating multiple email
Addresses.
User+whatever@gmail.com will get delivered to user@gmail.com. User@gmail.com1 won’t let them create an account.
Oh, but SSO was the point of this thread, so it’s not clear that my solution will help here. They’d still need to make every email address unique, one way or another.
I am incredibly late to this party, but if you are using your own SSO System (e.g. Not Google/GitHub/etc), then my plan is to use the user’s email, but make insert a +username before the @.
In the event that’s helpful to someone, that’s our current plan.
Again though, how would that work with SSO?
We implement our own Discourse SSO provider – so, it’s that system when can be adapted to send a unique email to Discourse. (e.g. user@gmail.com gets replaced with user+internal_id@gmail.com). When a user signs in, they don’t see any of thing, since they sign into our SSO system using their username.
Ultimately, this isn’t perfect, since that doesn’t deliver emails for everyone, but it does avoid real email clashes when you have systems where the email is not unique. (Sadly, the particular app that I am working with also has fewer user name restrictions than discourse, so clashes are possible, though so far very unlikely.)
I think the best long term solution may be to have a plugin which stores a separate notification email address, and have SSO send over a unique (possibly even faked?) email address and one for notifications that does not need to be unique. I’m not sure yet whether that will seriously break things, but ~30 minutes of skimming code suggests it’s plausible, if not a painful solution.
1 Like
This topic was automatically closed after 2488 days. New replies are no longer allowed.