Il provider SSO di Discourse non reindirizza a return_sso_url quando l'utente accede con SSO personalizzato

Supporto SSO
1

Per quanto ne so, lo stesso problema è stato menzionato due volte e si è detto che fosse stato risolto nel 2018 (Discourse doesn't redirect to return_sso_url after user logs in on private site) e nel 2015 (Login redirect during sso provider login). Tuttavia, sto ancora riscontrando lo stesso problema.

Nella nostra organizzazione abbiamo installato Discourse. Avendo un nostro database di account utente, utilizziamo il nostro sito web SSO personalizzato per consentire agli utenti di accedere a Discourse, seguendo le istruzioni disponibili su Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). Funziona bene.

Inoltre, abbiamo anche WordPress, Rocket Chat e un’app web Tornado personalizzata. Questi servizi dipendono da Discourse come provider SSO.

Per WordPress stiamo utilizzando wp-discourse. Per Rocket Chat e l’app web Tornado abbiamo seguito le istruzioni presenti su Use Discourse as an identity provider (SSO, DiscourseConnect).

Il flusso di accesso funziona correttamente se l’utente è già loggato su Discourse. Tuttavia, se l’utente non è già loggato su Discourse, nessuno dei flussi di accesso dei servizi (ad esempio WordPress/Rocket Chat/app web Tornado) funziona correttamente. Quando un utente tenta di accedere a WordPress, Rocket Chat o all’app web Tornado, viene reindirizzato a discourse.com/login. Quindi, l’utente clicca sul pulsante di accesso, che lo reindirizza al nostro sito SSO personalizzato. Qui esegue l’accesso, dopodiché viene reindirizzato a discourse.com, ma non al servizio desiderato (ad esempio WordPress, Rocket Chat o l’app web Tornado).

Solo un piccolo approfondimento: la funzione wp-discourse “Sync Logout with Discourse” non funziona. Quando un utente esce da WordPress, rimane comunque loggato su Discourse.

Sto affrontando questo problema da diversi mesi dopo diversi aggiornamenti di Discourse. Ora sto cercando aiuto. Fate sapere se sono necessarie ulteriori informazioni.

Il mio attuale workaround consiste nel reindirizzare l’utente non a /session/sso_provider, ma a /session/sso?return_path=customurl. Lo svantaggio è che viene sempre chiesto all’utente di effettuare l’accesso, anche se è già loggato su Discourse.

2

Durante l’accesso SSO personalizzato, l’app di lettura ha effettivamente letto ed estratto il return_sso_url dal cookie sso_payload. Tale return_sso_url è incorporato nel payload sso da inviare a /session/sso_login?. Ho potuto osservare nei log che return_sso_url era correttamente impostato, ma non è stata rilevata la reindirizzamento. Di seguito riporto il log:

add_groups:
admin:
moderator:
avatar_force_update:
avatar_url:
bio:
card_background_url:
email: xxx@xxx
external_id: 42
groups:
locale:
locale_force_update:
logout:
name: xxx
nonce: b4c758723a8abf665b079dc41a585dbc
profile_background_url:
remove_groups:
require_activation:
return_sso_url: https://customurl
suppress_welcome_message:
title:
username: xxx
website:
location:

3

@cylau1996 hai trovato una soluzione?

4

Qualche soluzione a riguardo?