Speriamo di avere una community in cui si ottiene un account solo come parte del processo di registrazione del nostro prodotto, ma vogliamo rendere visibile il contenuto del forum in modo che le persone che cercano di auto-aiutarsi tramite Google possano ottenere un risultato appropriato mentre sono non autenticate. (anche in modo da poter raggiungere alcuni obiettivi SEO per i nostri contenuti)
È possibile o è un sogno irrealizzabile? Sembra che non sia la prima persona a porre questa domanda, o a desiderare questa capacità del prodotto.
Quindi il problema è che alcuni utenti saranno registrati su Cognito e non vuoi che ricevano una finestra di dialogo di accesso se tentano di rispondere? Pensavo che con Discourse Connect fosse il comportamento predefinito.
Puoi rendere il sito aperto agli utenti anonimi e a Google.
In un mondo ideale, un utente che visualizza Discourse e ha un account dovrebbe essere sempre connesso, in questo modo possiamo acquisire tutti i dati di visualizzazione. Farò in modo che se un utente del prodotto clicca su un link nel prodotto per visualizzare la community, verrà autenticato, così come tutti i link che l’utente dovrebbe vedere solo se è autenticato altrove (pagina dell’account, per esempio).
Tuttavia, se un utente tenta l’auto-aiuto tramite Google e finisce nella community, non possiamo acquisire quei dati finché non tenta di interagire direttamente con la community, anche se è autenticato altrove nel nostro sistema. Sembra che l’unico modo per risolvere questo problema sia abilitare l’impostazione del sito login_required, che, se ho capito bene, rende effettivamente il sito privato.
Grazie. Non lo sapevo. Sono un CM che cerca di capire tutti i dettagli di tre prodotti separati e mi sta fondendo il cervello cercare di capire le particolarità di ognuno! Aspettatevi di vedere ancora qualche post da parte mia per cercare di risolvere tutto, e vi ringrazio per la pazienza.
Nel caso generale ciò sarà impossibile (come puoi dire se un utente anonimo ha un account senza invitarlo ad accedere?). Tuttavia, dovrebbe essere possibile rilevare se un utente ha già una sessione attiva sul tuo sito SSO.
Quell’argomento è piuttosto vecchio, ma penso che il principio dovrebbe ancora applicarsi. In sostanza, aggiungi un URL con un supporto CORS appropriato che restituisca una risposta JSON che indichi se l’utente ha una sessione attiva. Quindi aggiungi del JS al tuo tema Discourse che interroghi quell’URL e attivi il processo SSO se esiste una sessione attiva.
Temo che la risposta generale sia ancora in gran parte la stessa dell’ultima volta
La specifica di cui stavo parlando è OpenID Connect Session Management. Sfortunatamente, quella soluzione basata su iframe sta diventando sempre meno utile perché molti browser ora bloccano i cookie di terze parti per impostazione predefinita. Ora funziona in modo affidabile solo se il tuo identity provider e Discourse hanno la stessa ‘origine’.
Come ha detto @simonk, a seconda del tuo identity provider potrebbe essere possibile implementare qualcosa di personalizzato tramite un componente del tema, ma non sono a conoscenza di alcuna soluzione generale che potremmo aggiungere a Discourse stesso.
Hai perfettamente ragione sul fatto che fare clic su “rispondi” attiverà il flusso di accesso. E se viene utilizzato DiscourseConnect (o qualsiasi altro provider di accesso singolo), la modale di accesso di Discourse verrà saltata
Tuttavia, penso che l’OP voglia che le persone accedano automaticamente, senza dover fare clic su “rispondi” o “accedi”. Con questo tipo di configurazione, sarebbe totalmente trasparente per gli utenti spostarsi tra il sito principale e la community. Abbiamo ottenuto questo risultato per un paio di clienti, ma si sono trattati di implementazioni personalizzate che non possono essere facilmente generalizzate.
Per fornire un esempio di un approccio: se il tuo forum si trova su forum.example.com e il tuo sito principale si trova su example.com, allora al forum è consentito leggere i cookie da example.com. Pertanto, un componente del tema può verificare l’esistenza di un cookie ed eseguire un’operazione come questa:
const cookie = require("discourse/lib/cookie").default;
if(cookie('name_of_example_com_auth_cookie') && !api.getCurrentUser()){
// L'utente ha un cookie di autenticazione per example.com. È quasi certamente
// autenticato lì, quindi eseguiamo il flusso di autenticazione
window.location = "https://forum.example.com/auth/oidc"
}
(si applicano varie condizioni. ad esempio, il cookie non deve essere http_only, non deve essere un cookie host-only, ecc.)
Questo è effettivamente il caso. È bello sapere che è possibile, ma personalizzato.
Inoltre, dato che non sapevo che un utente che fa clic su “rispondi” saltasse la finestra di dialogo di accesso a seconda dell’implementazione, ciò allevierà molte delle mie preoccupazioni in primo luogo. Quella è la principale barriera all’ingresso che voglio evitare, e sono contento che possa essere implementata.
Naturalmente, il nerd dei dati in me vuole la versione ideale, ed è possibile che potremmo aspirare a quella. Sapere che è possibile per ora è abbastanza buono. Grazie ancora a tutti per il vostro tempo.
