Ciao, sto integrando Discourse con un sito della comunità in cui i membri possono già “bloccarsi” a vicenda. Quindi, quando un membro del mio sito effettua l’accesso tramite SSO su Discourse, vorrei passare anche l’elenco degli external_id bloccati. Immagino che questi possano semplicemente essere inseriti nel campo “Utenti silenziati” sul lato Discourse…
E se non è possibile, per realizzare questa funzionalità, sembra che dovrò configurare un webhook e, quando riceverò l’evento user_logged_in dal webhook, potrò quindi utilizzare l’API di Discourse per passare l’elenco degli utenti silenziati… è corretto? (E in tal caso: dove si trova questa chiamata nell’API? Non sono riuscito a trovarla!)
Sì, questo sembra in qualche modo simile ad altre estensioni che SSO ha già. È piuttosto raro averne bisogno, quindi sono indeciso se aggiungerlo al protocollo o meno.
Il webhook funzionerà: verrai chiamato al login, dopodiché potrai effettuare una seconda chiamata a Discourse per sincronizzare l’elenco tramite la nostra API.
Ciao Sam, sì, per il mio problema immediato risponderò semplicemente all’evento webhook user_logged_in — nessun problema. Grazie per questo.
Capisco il tuo punto di vista riguardo a ciò che può essere trasmesso tramite SSO. Mentre continuo a integrare profondamente Discourse con il mio sito, sto comprendendo meglio come voi abbiate scelto di implementare l’SSO. Funziona bene ora, ma in realtà penso che potrebbe essere interessante consolidare tutte le caselle di spunta “SSO overrides…” in una casella generale, tipo “L’SSO gestisce tutti gli attributi dell’utente” (o qualcosa di simile).
L’idea è che, se attivo questa casella globale SSO, l’unica cosa a cui devo attenermi è l’external_id: promettendo a Discourse che sarà sempre unico, identificherà sempre lo stesso utente e non cambierà mai. Una volta stabilito questo, potrei passare tutti i campi che desidero con la richiesta SSO e caricare l’utente completamente dal mio database.
se aggiungerlo al protocollo o meno.