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.
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.
@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.
Ich komme zu diesem Thema leider extrem spät, aber wenn du dein eigenes SSO-System verwendest (z. B. nicht Google, GitHub usw.), ist mein Plan, die E-Mail-Adresse des Benutzers zu verwenden und vor das @-Zeichen ein +Benutzername einzufügen.
Falls das für jemanden hilfreich ist, ist das unser aktueller Plan.
Aber wie würde das mit SSO funktionieren?
Wir setzen unseren eigenen Discourse-SSO-Anbieter ein – das ist also das System, das angepasst werden kann, um eine eindeutige E-Mail-Adresse an Discourse zu senden (z. B. wird user@gmail.com durch user+internal_id@gmail.com ersetzt). Wenn sich ein Benutzer anmeldet, sieht er davon nichts, da er sich über unser SSO-System mit seinem Benutzernamen anmeldet.
Letztendlich ist dies nicht perfekt, da nicht für alle Benutzer E-Mails zugestellt werden können, aber es vermeidet echte E-Mail-Konflikte in Systemen, bei denen die E-Mail-Adresse nicht eindeutig ist. (Leider hat die spezifische Anwendung, mit der ich arbeite, weniger Einschränkungen für Benutzernamen als Discourse, sodass Konflikte möglich sind, wenn auch bisher sehr unwahrscheinlich.)
Ich denke, die beste langfristige Lösung könnte ein Plugin sein, das eine separate Benachrichtigungs-E-Mail-Adresse speichert und über SSO eine eindeutige (möglicherweise sogar gefälschte) E-Mail-Adresse übermittelt, während die Benachrichtigungsadresse nicht eindeutig sein muss. Ich bin mir noch nicht sicher, ob dies Dinge ernsthaft stören würde, aber etwa 30 Minuten Code-Überprüfung deuten darauf hin, dass dies eine plausible, wenn auch nicht schmerzfreie Lösung ist.