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.
Llego increíblemente tarde a esta fiesta, pero si estás utilizando tu propio sistema SSO (por ejemplo, no Google/GitHub/etc.), entonces mi plan es usar el correo electrónico del usuario, pero insertar un +nombre de usuario antes del @.
En caso de que esto sea útil para alguien, ese es nuestro plan actual.
Aun así, ¿cómo funcionaría eso con SSO?
Implementamos nuestro propio proveedor de SSO para Discourse, de modo que el sistema puede adaptarse para enviar un correo electrónico único a Discourse (por ejemplo, user@gmail.com se reemplaza con user+internal_id@gmail.com). Cuando un usuario inicia sesión, no ve nada de esto, ya que accede a nuestro sistema SSO mediante su nombre de usuario.
En última instancia, esto no es perfecto, ya que no envía correos electrónicos para todos los usuarios, pero sí evita conflictos reales de correo electrónico en sistemas donde el correo no es único. (Lamentablemente, la aplicación específica con la que estoy trabajando tiene menos restricciones en los nombres de usuario que Discourse, por lo que los conflictos son posibles, aunque hasta ahora muy poco probables).
Creo que la mejor solución a largo plazo podría ser tener un plugin que almacene una dirección de correo electrónico de notificación separada, y que el SSO envíe una dirección de correo electrónico única (incluso posiblemente falsa) y otra para notificaciones que no necesite ser única. Aún no estoy seguro de si esto romperá seriamente las cosas, pero aproximadamente 30 minutos de lectura rápida del código sugieren que es plausible, aunque no necesariamente una solución sencilla.