Aiutami a risolvere i problemi con il mio SSO Discourse

Supporto
1

Saluti, spero di ricevere qualche indicazione. Il mio SSO ha smesso di funzionare questa settimana e pensavo di aver risolto tutto ieri (funzionava, lo giuro :slight_smile: Nota: ho dato un’occhiata a “Nuovi utenti” di ieri e oggi e ho avuto nuovi utenti in entrambi i giorni (dopo averlo corretto), ora è rotto di nuovo…). Purtroppo, gli aggiornamenti che ho apportato non funzionano oggi.

Problema: Gli utenti non possono creare nuovi account e gli utenti che disconnettono non possono accedere di nuovo.

Ho notato che il mio server Discourse restituisce errori 400 sulle seguenti rotte:

403: GET : discourse-url/users/by-external/USER-ID.json?
Nota: recentemente ho scoperto nella documentazione API che questa rotta non esiste? (anche se ha funzionato), sembra che la rotta sia: https://discourse.example.com/u/by-external/{external_id}.json

404: POST: discourse-url/admin/users/sync_sso?

Il motivo per cui il segno ? è alla fine è che ho un campo parametro opzionale in una funzione che genera URL; per queste due rotte tutti i dati vengono inviati nel corpo del modulo o negli header.

Sto utilizzando la seguente libreria.

Cosa ho aggiornato (e cosa pensavo avesse risolto il problema):

In tutte le mie richieste, stavo inviando Api-Key e Api-Username tramite un parametro di query. Negli ultimi mesi, ho notato nel mio pannello di amministrazione un avviso che indicava l’uso di header obsoleti nella mia richiesta. Mi ha indirizzato a questo post e i dettagli chiave sono qui:

:warning: Avviso di deprecazione!
Il 6 aprile 2020 abbiamo eliminato il supporto per tutte le autenticazioni basate su metodi diversi dagli header HTTP (esclusi alcuni percorsi per RSS, ricezione email e ICS). Ciò significa che le richieste API che includono api_key e api_username nei parametri di query o nel corpo HTTP smetteranno presto di funzionare. Si prega di consultare l’esempio di richiesta cURL riportato di seguito per aggiornare le proprie richieste API e utilizzare gli header HTTP per l’autenticazione.

Ho aggiornato tutte le mie richieste: ora tutte le richieste includono Api-Key e Api-Username nell’header e il tipo di contenuto è impostato su multipart form data.

Se qualcuno può offrire indicazioni su cosa indagare per risolvere questo problema, ne sarei molto grato. Sono quasi al 100% sicuro che funzionasse alla fine della mia giornata lavorativa di ieri: sono riuscito ad accedere e disconnettermi dal mio account e a creare nuovi account.

Fate sapere se avete bisogno di ulteriori informazioni. Grazie!

2

I campi dell’intestazione devono utilizzare trattini (-), non sottolineature (_). Prova a cambiare i nomi dei campi in Api-Key e Api-Username.

Non sono sicuro che questo risolverĂ  il problema per cui gli utenti non riescono ad accedere al tuo sito, ma risolverĂ  il problema degli errori 400 che stai riscontrando.

3

@simon, grazie per la risposta! Purtroppo non ho documentato bene il mio post: nei miei request sto giĂ  usando - e non _.

4

Per iniziare a risolvere il problema, vai alla pagina delle impostazioni del tuo sito Discourse e cerca ‘sso’ per visualizzare tutte le tue configurazioni SSO. Assicurati che le impostazioni enable sso, sso url e sso secret siano corrette. Quindi, attiva l’impostazione del sito verbose sso logging. Con questa impostazione attiva, verranno aggiunte alcune voci di log aggiuntive ai registri degli errori del tuo sito (trovabili in Amministrazione / Log / Log degli errori).

Prova ad accedere tramite SSO. Quindi, controlla i registri degli errori per vedere se forniscono dettagli sul problema. Se non vedi nulla di utile, apri gli strumenti per sviluppatori del tuo browser sulla scheda Rete e assicurati che la casella di controllo “Preserva log” sia selezionata. Esamina le richieste in corso.

Se ti blocchi fuori dal tuo sito mentre cerchi di risolvere il problema, in qualità di amministratore puoi bypassare l’SSO andando su /u/admin-login e inserendo il tuo indirizzo email nel modulo. Ti verrà inviato un’email con un link di accesso.

5

@simon, grazie per il consiglio! Ho esaminato i log, ma non sono molto esperto nel leggerli. Ricevo due tipi diversi di avvisi e un errore:

Ecco l’avviso che ricevo frequentemente:

Verbose SSO log: Started SSO process add_groups: admin: moderator: avatar_force_update: avatar_url: bio: card_background_url: email: external_id: groups: locale: locale_force_update: logo

Ecco l’errore:

Job exception: The difference between the request time and the current time is too large.

Quando provo ad accedere come utente di test sul mio sito, da cui mi sono disconnesso su Discourse, nel pannello di rete visualizzo quanto segue:

503 Service Unavailable: GET- https://my-site/auth/discourse_sso?sso=XXXX&sig=xxxx

Purtroppo, mi sono imbattuto in un ostacolo e non so come procedere.

6

Penso che quel messaggio di errore provenga da Amazon S3. Potrebbero esserci dettagli utili su come risolvere il problema in questo argomento: Backups have started failing due to server time being wrong. Ci sono ulteriori informazioni qui: https://stackoverflow.com/questions/4770635/s3-error-the-difference-between-the-request-time-and-the-current-time-is-too-la.

7

@simon grazie per l’aiuto! L’orario del mio server non era sincronizzato, l’ho aggiornato e ora i backup funzionano di nuovo!

Ora ricevo sporadicamente un nuovo errore:

Nella sezione dei log, ricevo in modo casuale i seguenti avvisi (li ho ricevuti solo 2 volte):

MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-City.mmdb) non trovato: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-City.mmdb

e

MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-ASN.mmdb) non trovato: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-ASN.mmdb

Sto cercando informazioni su come risolvere questo problema; ho provato a ricreare la mia applicazione, ma non sono sicuro al 100% che il processo di ricreazione abbia avuto successo. Ricevo ancora in modo casuale gli errori “MaxMindDB non trovato”, oltre agli errori 400 e all’errore 503 che ricevevo in precedenza.

8

Ho lavorato a questo per gran parte della mattina presto senza ottenere molti progressi. Penso di aver eliminato gli errori MaxMindDB (prima erano sporadici e incoerenti, ma non sono riuscito a ripeterli nelle ultime 3 ore) e ho ricompilato la mia applicazione diverse volte con successo.

Ecco dove si interrompe la pipeline SSO:

  • l’utente visita Discourse
  • PoichĂŠ non c’è una sessione attiva, l’utente viene reindirizzato a discourse/session/sso_login
  • L’utente viene reindirizzato a my-site/discourse_sso?sso=XXXX&sig=XXXX
  • Quando viene raggiunto il percorso precedente dal mio sito, invio una richiesta GET a /users/by-external/userId.json
    • questa restituisce un 403 Forbidden
  • Immediatamente dopo viene inviata una richiesta POST a /admin/users/sync_sso
    • questo genera un errore 404 "No route matches [POST] /admin/users/sync_sso
  • Alla fine, il mio sito restituisce un messaggio di errore 503 Forbidden (devo ripulire alcuni messaggi di errore lato mio sito)

Sento che l’errore sia sul lato dell’applicazione Rails (per favore correggetemi se sbaglio). Un motivo per cui la penso così è che, alla fine della giornata di venerdì, tutto funzionava: ce n’è la prova perché tra venerdì sera e sabato alcuni nuovi utenti si sono registrati (ed era proprio l’accesso o la creazione di un nuovo utente a non funzionare). Come ho menzionato nei post precedenti, pensavo di aver risolto tutto, ma quando ho ripreso a lavorare sabato ho notato che era di nuovo rotto.

9

Non sono sicuro del motivo per cui state inviando richieste a /users/by-external/<external_id>.json e /admin/users/sync_sso. Il flusso normale sarebbe semplicemente reindirizzare l’utente a /session/sso_login con il payload SSO impostato come parametri di query nell’URL. Qui ci sono dettagli su a cosa serve la rotta sync_sso: Sync DiscourseConnect user data with the sync_sso route.

Inviare una richiesta a /users/by-external/<external_id> con un external_id che non è ancora associato a un utente Discourse dovrebbe restituire un errore 404 (non trovato). Se l’external_id è associato a un utente Discourse, dovrebbe essere restituito l’utente.

10

@simon, La richiesta a /users/by-external/USER-ID.json serve a verificare se l’utente ha già un account sul mio Discourse. Se viene trovato un utente con quell’ID, viene aggiunto/rimosso dai gruppi di Discourse associati al mio sito tramite una richiesta PUT a /admin/groups/groupId/members.json, quindi viene reindirizzato a my-discourse/session/sso_login.

Se l’utente non ha un account, questo viene creato tramite una richiesta POST a /admin/users/sync_sso e, dopo la creazione dell’utente (e l’aggiunta ai suoi gruppi Discourse corretti), viene reindirizzato a my-discourse/session/sso_login.

Procederò a rileggere la documentazione che hai elencato (grazie!). Questo flusso funziona senza intoppi dall’inizio del 2015 (e l’opzione SSO di Discourse è stata uno strumento così prezioso per noi!), quindi è strano che abbia smesso improvvisamente di funzionare nella scorsa settimana.

11

@simon Apprezzo davvero molto tutto il tuo aiuto! Ho risolto il problema. L’Api-Username che stavamo usando è stato “disattivato” la scorsa settimana (a causa di inattività). Avevo inizialmente ipotizzato che potesse essere quello il problema. Ho riattivato l’utente venerdì e, molto probabilmente, è stato questo a risolvere tutto venerdì (in origine pensavo che fosse lo spostamento di Api-Username e Api-Key nell’Header).

Discourse ha disattivato lo stesso utente di nuovo sabato mattina, il che spiega perché tutto funzionava e poi si è bloccato improvvisamente. Non pensavo che l’utente sarebbe stato disattivato di nuovo così presto a causa dell’inattività.

Ho modificato ora l’Api-Username in “system” per evitare che questo si ripeta in futuro. Grazie ancora per il tuo aiuto; nel processo di debug dei log, i miei backup sono tornati a funzionare e ho certamente imparato molto!