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.
Sono incredibilmente in ritardo a questa festa, ma se state utilizzando il vostro sistema SSO (ad esempio non Google/GitHub/altro), il mio piano è utilizzare l’email dell’utente, inserendo un +username prima della @.
Nel caso in cui questo sia utile a qualcuno, questo è il nostro piano attuale.
Tuttavia, come funzionerebbe con SSO?
Implementiamo il nostro provider SSO per Discourse: quindi, è quel sistema che può essere adattato per inviare un indirizzo email univoco a Discourse (ad esempio, user@gmail.com viene sostituito con user+internal_id@gmail.com). Quando un utente accede, non vede nulla di tutto ciò, poiché effettua il login al nostro sistema SSO utilizzando il proprio nome utente.
In definitiva, questa soluzione non è perfetta, dato che non garantisce la consegna delle email per tutti, ma evita conflitti reali di indirizzi email in sistemi in cui l’email non è univoca. (Purtroppo, l’applicazione specifica con cui sto lavorando ha anche meno restrizioni sui nomi utente rispetto a Discourse, quindi i conflitti sono possibili, anche se finora molto improbabili.)
Penso che la migliore soluzione a lungo termine possa essere quella di avere un plugin che memorizzi un indirizzo email separato per le notifiche, e che l’SSO invii un indirizzo email univoco (forse anche finto?) e un altro per le notifiche che non deve essere univoco. Non sono ancora sicuro che questo possa rompere seriamente le cose, ma circa 30 minuti di analisi del codice suggeriscono che sia plausibile, anche se non una soluzione priva di inconvenienti.