Sto lavorando su un sito WordPress che ha un forum Discourse collegato con circa 200.000 utenti.
Utilizzando i plugin OAuth Single Sign On - SSO (OAuth client) e WP-Discourse, colleghiamo i post da WP a Discourse e permettiamo agli utenti di accedere su WP con la loro istanza utente WP, che poi li collega anche a Discourse.
Ora è sorto un problema, ogni volta che impostiamo le impostazioni di Discourse su non richiedere l’accesso.
Questi sono i nostri passaggi:
L’utente accede a WordPress
L’utente clicca su un link che porta a Discourse (un argomento, qualsiasi link che porta a Discourse)
==> L’utente ora vede Discourse come se non fosse loggato! Ma è loggato, nel momento in cui ha effettuato l’accesso a WordPress!
Ora l’utente clicca sul login di Discourse o su qualsiasi link di argomento
La pagina si aggiorna e l’utente è ora autenticato!
Ci è stato detto che questo è previsto e che dobbiamo fare quanto segue:
quando l’utente è loggato, tutti i link che portano a Discourse da WordPress devono essere i seguenti: https://our-discourse-instance.com/session/sso?return_path={URL ORIGINALE DI DISCOURSE A CUI CI RIFERIAMO, come un URL di argomento, o simile}
quando un utente non è loggato, possiamo collegarci direttamente a {URL ORIGINALE DI DISCOURSE A CUI CI RIFERIAMO, come un URL di argomento, o simile}, così https://our-discourse-instance.com/t/topic-slug
Sospetto fortemente che questo sia l’approccio sbagliato per risolvere questo problema, perché:
E se un utente, mentre è loggato su Discourse, copia l’URL di un argomento e lo condivide con qualcuno che è anche loggato su WP/DIscourse? Otterrebbero lo stesso errore mostrato sopra al punto 2, poiché non verrebbe aggiunto alcun suffisso URL di questo tipo.
Perché un utente loggato dovrebbe essere reindirizzato a session/sso?return_path=? Qual è il ragionamento tecnico e la logica dietro questo?
Perché si risolve non appena l’utente ricarica la pagina (carica un URL di argomento, preme login, ecc.)?
Perché questo non è più ampiamente documentato, se fosse l’approccio effettivo previsto?
Perché questo non verrebbe menzionato nell’API, dove siamo in grado di recuperare qualsiasi URL di argomento da Discourse, e da nessuna parte è scritto che gli utenti loggati non saranno in grado di raggiungere immediatamente il contenuto e dovranno prima fare strani ricaricamenti, o che dobbiamo aggiungere strani parametri URL che, di fatto, non convertono nulla?
Apprezzerei davvero un’opinione autorevole su questo, perché non sono affatto convinto che questo sia il comportamento previsto!
Se lo è, vorrei chiedere:
perché questo è effettivamente necessario e
cosa si prevede di fare a riguardo (perché questo sicuramente non è l’ideale, vedi punto 1 delle mie ragioni sul perché questo non dovrebbe essere previsto)
Se desideri che i tuoi utenti vengano reindirizzati automaticamente al login quando accedono a qualsiasi percorso del tuo forum, dovrai abilitare l’impostazione login required. Questo è effettivamente il comportamento previsto.
Anche se sembra ancora strano, ho proceduto ad aggiungere un reindirizzamento a session/sso?return_path= al login dell’utente in wp
Il percorso di ritorno che ho impostato è il referrer da wp (se presente) o la homepage di wp
Ciò funziona benissimo e garantisce che l’utente sia loggato in entrambe le istanze
Ho dovuto abilitare l’impostazione in discourse per consentire “qualsiasi percorso di ritorno”, poiché per impostazione predefinita discourse non consente percorsi di ritorno “esterni”
Vedi qualche problema nell’abilitare questa impostazione?
Grazie ancora per la gentile risposta e la conferma “ufficiale” più il link alla documentazione!
In genere sconsiglio ai clienti di effettuare un reindirizzamento automatico di questo tipo. Capisco perché lo ritieni un problema, è una sensazione non rara, tuttavia l’approccio standard funziona benissimo per molti siti, grandi o più grandi del tuo, e il reindirizzamento automatico potrebbe non funzionare in alcuni scenari, portando a una scarsa esperienza utente.
Il login-una-volta-login-automaticamente-ovunque che ti aspetti è il modo in cui funzionano a volte i servizi interconnessi come Meta (ad esempio, accedi a Facebook e sei loggato su Instagram) perché sono piattaforme controllate centralmente (anche se anche i servizi centralizzati a volte funzionano allo stesso modo di DiscourseConnect).
Al contrario, qui hai a che fare con framework software open-source indipendenti (cioè Wordpress e Discourse). Possono essere configurati per funzionare efficacemente nel modo che ti aspetti, ma richiede un lavoro personalizzato specifico che tenga conto del tuo caso d’uso specifico. Non sarà mai il modo in cui funziona un sistema di autenticazione come DiscourseConnect, che serve migliaia di casi d’uso diversi.
No, con la precisazione che metterei in discussione la premessa della necessità. Ma senza ulteriori informazioni non vedo problemi nell’utilizzarla.
Potrebbe trattarsi di un rischio di reindirizzamento non convalidato, come descritto qui?
Posso vedere come “consentire qualsiasi valore di ritorno” consenta effettivamente di reindirizzare ovunque
Ma non sono sicuro se questo sarebbe davvero un rischio, poiché nessun dato sensibile viene condiviso nell’URL di reindirizzamento o verso di esso.
Mi dispiace, ciò significherebbe avventurarsi nel dare consigli su una parte sensibile della tua configurazione senza vederla di persona o avere un rapporto definito con te.
In particolare, data la dimensione del tuo forum e le normative pertinenti che si applicano ad esso, ti consiglio di ottenere consigli specifici e informati su tale questione.
Un forum Discourse attiva l’impostazione in Discourse per consentire “qualsiasi percorso di ritorno”
Ciò significa che ora puoi visitare il tuo-discourse.tld/session/sso?return_path=QUALSIASI_COSA
QUALSIASI_COSA potrebbe essere un URL esterno
Ciò apre una vulnerabilità di sicurezza in termini di almeno un tentativo di phishing che potrebbe essere messo in scena:
un sito web dannoso crea un pulsante dicendo “vai alla fantastica community!”
il link del pulsante è il tuo-discourse.tld/session/sso?return_path=TORNA AL SITO MALIGNO
l’utente preme il pulsante, accede alla community, che lo riporta al SITO MALIGNO
lì, l’attore dannoso ha implementato una pagina che assomiglia esattamente alla community e dice “qualcosa è andato storto durante l’accesso, riprova”
l’utente invia un modulo di accesso dall’aspetto gradevole che corrisponde all’aspetto della community
L’attore dannoso ha ora catturato i dati di accesso?
Pertanto, probabilmente l’impostazione “qualsiasi percorso di ritorno” non dovrebbe mai essere utilizzata per un sito in cui gli utenti accedono, a meno che ogni singolo utente non sappia esattamente cosa cercare.
Vedresti anche tu quel rischio?
Perché gli sviluppatori di Discourse che creano plugin/codice che possono interagire con questa impostazione non potrebbero dare un cenno in “sì nessun problema” o “assolutamente no”?
Non sono molte le cose che possono cambiare in quel parametro URL. O c’è o non c’è, o consente esterni o non li consente.
Forse sto curiosando in un’area in cui non dovrei, come in “non discutere qui di problemi di sicurezza”? Lo capirei certamente, molte piattaforme non consentono di parlare apertamente di potenziali problemi di sicurezza che non sono chiaramente definiti al momento dell’attivazione
Perché la valenza delle impostazioni dipende da come vengono utilizzate, infatti è per questo che sono impostazioni e non solo “funzionalità”. Se ci fosse una risposta semplice alla tua domanda, non ci sarebbe un’impostazione in primo luogo.
Apprezzo che questa risposta un po’ legale sia frustrante. Ma hai bisogno di consigli specifici per il tuo caso d’uso, che non sono nella posizione di darti qui.
