Lo scenario peggiore di cui sono a conoscenza richiede queste condizioni:
- gli indirizzi email non sono verificati sul sito esterno
require_activation=truenon è impostato nel payload SSO- ci sono account esistenti sul sito Discourse che non hanno un
SingleSignOnRecordassociato (il proprietario dell’account non ha mai effettuato l’accesso a Discourse tramite SSO)
In quel caso, qualcuno potrebbe registrarsi sul sito esterno utilizzando l’indirizzo email di un utente Discourse che non ha mai effettuato l’accesso tramite SSO. Ciò consentirebbe all’account non verificato dal sito esterno di impossessarsi dell’account Discourse che utilizza lo stesso indirizzo email. Ciò sarebbe particolarmente preoccupante se si trattasse di un account amministratore su Discourse.
È consigliato che Discourse gestisca la verifica dell’email se il sito esterno non la gestisce:
Ci sono un paio di ragioni per cui è meglio gestire la verifica dell’email sul sito esterno:
- forzare gli utenti a ricevere l’email di conferma da Discourse aggiunge un attrito quando gli utenti tentano per la prima volta di accedere a Discourse. (Realisticamente, quell’attrito deve comunque avvenire da qualche parte, o da parte di Discourse o da parte del sito esterno.)
- Discourse non assocerà gli account Discourse esistenti agli accessi esterni in base all’indirizzo email se
require_activationè impostato sutruenel payload SSO. Questo è un problema se abiliti DiscourseConnect dopo che alcuni account sono stati creati su Discourse registrandosi con nome utente/password. È anche un problema se per qualsiasi motivo devi eliminare le vociSingleSignOnRecordsu Discourse. Discourse non creerà automaticamente nuove vociSingleSignOnRecordquando gli utenti tenteranno di accedere nuovamente a Discourse.