(oauth2_basic) Errore di autenticazione! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | Rilevato CSRF
Avete qualche idea?
(oauth2_basic) Errore di autenticazione! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | Rilevato CSRF
Avete qualche idea?
È possibile rendere Auth0 l’unico metodo disponibile per registrarsi e accedere?
Sì, disabilita semplicemente tutti gli altri metodi di accesso (inclusa l’impostazione “abilita accessi locali”).
È possibile reindirizzare direttamente alla registrazione di Auth0 senza visualizzare il modulo di registrazione di base?
Se desideri nascondere tutta l’interfaccia di accesso/registrazione di Discourse, puoi disattivare l’impostazione del sito “abilita accessi locali”.
Grazie, David. L’ho fatto, ma ho notato che quando mi iscrivo tramite il modal e vengo reindirizzato su Discourse, viene richiesto nuovamente nome utente e altri dettagli, quindi sembra che Auth0 non stia trasmettendo queste informazioni a Discourse. Mi chiedo se la soluzione sia mantenere il modal semplice, con solo indirizzo email e password per la registrazione su Auth0, e raccogliere il resto dei dettagli su Discourse.
Il problema è che vogliamo mantenere i dati utente in un unico posto, utilizzando un database personalizzato collegato ad Auth0.
Come posso impostare il reindirizzamento dopo il logout? Non riesco a trovare nulla a riguardo.
Per richiedere la convalida dell’indirizzo email solo se l’utente non l’ha già confermata in Auth0, il valore di oauth2 json email verified path è email_verified.
L’ho trovato abilitando l’impostazione oauth2 debug auth e ispezionando i log su \u003cDISCOURSE_URL\u003e/logs. Quando ho effettuato l’accesso utilizzando un account non verificato, il corpo era simile a questo:
OAuth2 Debugging:
user_json: {
"sub"=>"auth0|XXXXXX",
"nickname"=>"YYYYY+unprovenauth",
"name"=>"YYYYYY+unprovenauth@ZZZZZZ.com",
"picture"=>"https://via.placeholder.com/150",
"updated_at"=>"2022-09-21T07:50:40.172Z",
"email"=>"YYYYYY+unprovenauth@ZZZZZZ.com",
"email_verified"=>false
}
@david
Spero tu possa aiutarmi: vorrei configurare Discourse per accedere utilizzando il login XBL di Microsoft e pensavo che questo plugin potesse essere un buon punto di partenza.
Ho pubblicato questo thread in dev:
C’è un forum Discourse di Minecraft chiamato “The Hive” che utilizza ciò che vogliamo fare: non riesco solo a trovare un plugin per esso. ![]()
Ciao!
C’è un modo per richiedere l’accesso per pubblicare nella community, ma consentire la visualizzazione dei post senza accedere?
Abbiamo abilitato il plugin Auth0 per la nostra community. E abbiamo rimosso tutte le altre forme di accesso e pubblicazione anonima: vogliamo essenzialmente assicurarci che le persone siano nostri clienti prima che pubblichino nella community utente. Ma vorremmo comunque che i post fossero visualizzabili da altri anche se non hanno effettuato l’accesso.
Il modo in cui sono riuscito a far funzionare il plugin Auth0, richiede di accedere prima ancora di visualizzare il contenuto. Mi manca un’impostazione o qualcos’altro?
Grazie!
Sembra che tu possa aver attivato login required. Con questa opzione abilitata, solo le persone con un account possono visualizzare i post del forum. Dovresti essere in grado di avere SSO senza dover abilitare questa opzione. ![]()
questo URL viene restituito subito dopo la creazione della registrazione e prima che l’utente finale possa convalidare la propria email in auth0 È possibile impedire il passaggio alla community prima che l’email venga convalidata?
Sto riscontrando alcuni problemi nell’impostazione. Dopo aver abilitato tutto e aver completato il processo di registrazione sul mio Discourse, viene inviato correttamente ad Auth0, ma quando torno vedo un messaggio di errore (“Oops Il software che alimenta questo forum di discussione ha riscontrato un problema imprevisto. Ci scusiamo per l’inconveniente.”).
Guardando nei log vedo quello che penso sia l’errore:
ActiveRecord::NotNullViolation (PG::NotNullViolation: ERROR: null value in column "provider_uid" of relation "user_associated_accounts" violates not-null constraint
Ho ricontrollato di aver configurato tutto secondo le istruzioni, sembra che questo problema possa essere causato dal fatto che il campo “OAuth2 JSON user ID path” sia errato e vuoto? L’ho impostato su sub.
Supponendo che l’IDP fornisca campi separati come user.name.first e user.name.last, invece di user.name.full come indicato nell’esempio della descrizione del campo…
Sarebbe possibile concatenare il valore del percorso del nome JSON di OAuth2 da più percorsi di dati utente JSON?