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.
이 파티에 엄청 늦게 합류하게 됐는데, 만약 여러분이 자체 SSO 시스템(예: Google/GitHub 등)을 사용하고 있다면, 제 계획은 사용자의 이메일 주소를 사용하되 @ 앞에 +username을 삽입하는 것입니다.
혹시 누군가에게 도움이 될 수 있다면, 이것이 저희의 현재 계획입니다.
하지만 그럼 SSO와 어떻게 연동되는 걸까요?
우리는 자체 Discourse SSO 제공자를 구현했습니다. 즉, Discourse로 고유한 이메일을 전송하도록 조정할 수 있는 시스템입니다. (예: user@gmail.com이 user+internal_id@gmail.com으로 대체됨). 사용자가 로그인할 때, 이들은 사용자명으로 SSO 시스템에 로그인하기 때문에 아무런 변화도 인식하지 못합니다.
결국, 이는 모든 사용자에게 이메일을 전달하지는 못하므로 완벽하지는 않지만, 이메일이 고유하지 않은 시스템에서 실제 이메일 충돌을 방지할 수 있습니다. (불행히도, 제가 작업 중인 특정 앱은 Discourse보다 사용자명 제한이 적어 충돌이 가능하지만, 지금까지는 매우 가능성이 낮았습니다.)
장기적으로 최선의 해결책은 별도의 알림 이메일 주소를 저장하는 플러그인을 만들고, SSO가 고유한(심지어 가짜?) 이메일 주소와 고유하지 않아도 되는 알림용 이메일 주소를 함께 전송하도록 하는 것일 수 있습니다. 이것이 실제로 문제를 일으킬지는 아직 확신할 수 없지만, 코드를 약 30분간 대략적으로 살펴본 결과, 고통스러운 해결책이긴 하더라도 실현 가능해 보입니다.