È l’unica cosa che fa questa impostazione?
La trovo chiamata e descritta in modo piuttosto vago in WP, quindi mi stavo chiedendo cos’altro potrebbe fare?
Riguardo a questo,
cosa succede se un utente esiste già sia in WordPress che in Discourse? Come faccio a unire / collegare i loro profili?
Tecnicamente, quello che fa è effettuare una chiamata alla route sync_sso di Discourse e passare i loro dati (user_id di WordPress, username, nome, email…) a Discourse immediatamente dopo che hanno effettuato l’accesso a WordPress. I dettagli sulla route sync_sso sono qui: Sync DiscourseConnect user data with the sync_sso route.
L’unico effetto collaterale di cui sono a conoscenza per gli utenti di WordPress che non hanno mai visitato il sito Discourse è che inizieranno a ricevere email digest da Discourse.
Ecco perché vuoi incoraggiare i tuoi utenti di Discourse a registrarsi su WordPress con lo stesso indirizzo email che stanno utilizzando su Discourse. Finché gli indirizzi email corrispondono, verranno effettuati nell’account Discourse corretto. Questo presuppone che tu ti occupi della questione della verifica dell’email di cui abbiamo discusso nei post precedenti.
È probabile che finirai con alcuni utenti che si registrano su WordPress con indirizzi email diversi da quelli che hanno utilizzato su Discourse. In tal caso, verrà creato un nuovo account Discourse per loro, utilizzando l’indirizzo email di WordPress. Dovrai unire manualmente il vecchio account Discourse nel nuovo account Discourse: Merging user accounts.
3 Mi Piace
Cosa succede se dobbiamo aggiornare manualmente l’email di un utente in Wordpress? La loro email di Discourse viene aggiornata anche se questa impostazione è abilitata?
1 Mi Piace
L’aggiornamento di un utente dalla sua pagina del profilo WordPress non attiva la chiamata a sync_sso. Probabilmente dovrebbe farlo, però. Per ora, dovrai chiedere loro di disconnettersi da WordPress, quindi di accedere nuovamente a WordPress. Non credo sia possibile per un amministratore disconnettere un utente di WordPress dalla sua pagina del profilo.
Se desideri mantenere sincronizzati le email e/o i nomi utente tra WordPress e Discourse, abilita queste impostazioni di Discourse:
auth overrides emailauth overrides username
1 Mi Piace
Grazie Simon. Penso che questo sia il processo che seguirò dopo aver considerato tutto:
- Esporta gli utenti da Discourse
- Attiva Discourse Connect
- Importa e crea quegli utenti in Wordpress e contrassegna le loro email come verificate in WP
- Quando questi utenti effettuano l’accesso (tramite una pagina di accesso personalizzata) dovranno reimpostare la password
- In qualche modo forza solo questo segmento di utenti a cambiare la password dopo che inseriscono la loro email (e il sistema si rende conto che fanno parte di questo segmento)
- OPPURE mostra semplicemente un messaggio sulla pagina di accesso: “se accedi dopo il [data] devi REIMPOSTARE la tua password”
- L’accesso dovrebbe funzionare!
Per quanto riguarda le nuove registrazioni in arrivo, dovrò trovare un modo per verificare le email. Probabilmente invierò loro le password via email.
Ho anche notato che anche se l’impostazione “Email Address Verified” non è selezionata nel profilo di Wordpress, l’utente è comunque in grado di effettuare l’SSO su Discourse. Devono comunque confermare la loro email la prima volta che entrano in Discourse. Il che è positivo.
Queste impostazioni hanno effetti collaterali?
1 Mi Piace
Sì, è così che è inteso che funzioni. Non è una grande barriera per la maggior parte degli utenti. Il problema di cui devi essere consapevole è che se l’indirizzo email non è contrassegnato come verificato su WordPress, Discourse non abbinerà gli utenti di WordPress agli utenti di Discourse in base al loro indirizzo email la prima volta che accedono a Discourse tramite DiscourseConnect. Finché riesci a capire come contrassegnare gli indirizzi email dei tuoi utenti importati come verificati, questo non causerà problemi. Se non li contrassegni come verificati, sarà un problema risolverli.
Se abilitate, impediscono agli utenti di modificare il loro nome utente o indirizzo email su Discourse.
1 Mi Piace
sì, stavo testando molto e me ne sono reso conto. Scriverò solo uno script personalizzato che contrassegnerà tutti gli utenti che importo come verificati.
Grazie per aver chiarito!
1 Mi Piace
È corretto mantenere sempre attivo il verbose /logs?
Ciò avrà un impatto negativo sulle prestazioni?
Ho visto casi in cui sono rimasti sempre attivi. Non credo che abbia un impatto significativo sulle prestazioni. Ingombra solo i tuoi log se stai cercando di eseguire il debug di un problema non correlato a DiscourseConnect.
2 Mi Piace
Finora tutto ha funzionato alla grande!
Una piccola cosa che sto notando è che qualsiasi percorso inserisca in questo campo:
diventa la pagina di accesso predefinita di WordPress.
Ad esempio, se provo ora ad andare su /wp-admin, che è quello che usavo in precedenza per accedere come amministratore, mi reindirizza a /login/forum
Idealmente, dovrebbe reindirizzare a questo solo quando qualcuno fa clic sul pulsante di accesso dal forum di discourse.
Mi chiedo se questo sia il comportamento normale e se sia un problema che funzioni in questo modo.
Questo è il comportamento previsto. L’opzione “Percorso della tua pagina di accesso” viene utilizzata per sovrascrivere il percorso di accesso predefinito di WordPress. Lo fa agganciandosi al filtro login_url di WordPress.
Non rimuove il percorso di accesso predefinito in /wp-login.php, quindi puoi ancora accedere direttamente a quell’URL inserendolo nella barra degli indirizzi del tuo browser. Invece di andare su /wp-admin, vai su /wp-login.php per utilizzare la pagina di accesso predefinita.
Mi viene in mente un modo in cui il plugin potrebbe essere aggiornato per reindirizzare solo al percorso “Percorso della tua pagina di accesso” per l’accesso a Discourse, ma tale modifica richiederebbe un po’ di lavoro.
4 Mi Piace
Nessun problema. Solo una piccola cosa. Grazie per gli spunti!
1 Mi Piace
Ciao @simon, sto riscontrando i seguenti errori nel mio log e mi chiedevo cosa significassero e come affrontarli. Ho notato questi errori dopo che un utente ha segnalato di ricevere un errore durante il tentativo di accesso.
-
(google_oauth2) Authentication failure! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected
-
Authentication failure! request_error: OAuth::Unauthorized, 401 Unauthorized
-
(facebook) Authentication failure! no_authorization_code: OmniAuth::Strategies::Facebook::NoAuthorizationCodeError, must pass either a
code(via URL or by anfbsr_XXXsigned request cookie)
Vale la pena notare che questi errori non sono comuni. La maggior parte dei log sembra funzionare correttamente:
ho appena ricevuto questo screenshot dall’utente:
Ha detto: “Non c’è email. Non appena fai clic sul link di iscrizione, ti viene presentata la seguente pagina…”
quando faccio clic sul link di accesso/iscrizione (in incognito), funziona per me.
Ecco l’URL del nostro forum come riferimento: forum.projectvanlife.com
Presumo che le voci che iniziano con “Verbose SSO log” mostrino accessi riusciti.
Per gli errori “google_oauth2”, “OAuth::Unauthorized” e “facebook”, non sono sicuro di cosa stia succedendo. Il tuo sito Discourse era precedentemente configurato per consentire agli utenti di accedere tramite Google e Facebook? In tal caso, non potranno più accedere al sito con quei metodi ora che DiscourseConnect è abilitato. Forse prova a disabilitare gli accessi a Google e Facebook dalla tua pagina delle impostazioni di Discourse.
Per gli utenti che segnalano errori di accesso, prova a trovare un messaggio di errore nel log SSO dettagliato associato al tentativo di accesso dell’utente. Quindi verifica se l’errore corrisponde a uno dei problemi descritti in questo argomento: Debug and fixing common DiscourseConnect issues.
L’URL mostrato nella barra degli indirizzi del browser è https://projectvanlife.com/login/forum/javascript%3Avoid(0.
Presumo che parte del javascript venga troncato e che in realtà sia inteso per essere decodificato in javascript:void(0). Non sono sicuro da dove possa provenire. Possibilmente da una delle estensioni del browser dell’utente. Prova a chiedere loro di disabilitare le estensioni del browser o di provare ad accedere da una finestra di navigazione in incognito.
Modifica: @Sami_Syed il codice javascript:void(0) viene aggiunto al percorso quando si fa clic sul link “Iscriviti” della pagina di accesso. L’href di quel link è: \"javascript%3Avoid(0)\"
Immagino che venga utilizzato per avere il modulo di iscrizione sullo stesso percorso del modulo di accesso. Tuttavia, qualcosa sta andando storto. Sai se questo funzionava correttamente prima che DiscourseConnect fosse abilitato?
Se il plugin utilizzato per i moduli di accesso/iscrizione ha un’opzione per far apparire il modulo di iscrizione su una pagina separata, abilitarla dovrebbe funzionare come soluzione rapida al problema.
Sarò offline per la maggior parte di oggi, ma posso provare ad aiutarti più tardi se sei bloccato.
Modifica: Ero perplesso riguardo a questo, quindi ho dato un’altra occhiata. La scheda “Registrati” sul modulo di accesso funziona senza problemi. Il link “Iscriviti” presenta il problema che ho descritto sopra:
Quindi la soluzione rapida al problema è semplicemente rimuovere il link di iscrizione.
2 Mi Piace
Corretto.
Sì, era abilitato. La domanda è però, come riescono ancora ad attivare un accesso tramite FB o Google? La nostra attuale pagina di accesso non ha quella funzionalità.
O questo errore si presenta per coloro che si sono registrati originariamente usando G o FB e ora stanno cercando di accedere ma non funziona?
E in tal caso, come posso risolverlo?
Per quanto vedo, è perché non ho impostato un link corretto lì. Oops. Ben notato e grazie!
Non so cosa possa causarlo. Forse l’URL del provider di autenticazione è stato memorizzato nella cache dal browser dell’utente. Questa è solo un’ipotesi, però.
1 Mi Piace
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.