Ho riscontrato lo stesso problema e lo fa durante l’accesso con Google. Prima di WordPress, utilizziamo Nginx come proxy inverso. Potrebbe essere correlato?
Presumo che questo stia accadendo durante l’accesso a WordPress tramite il tuo sito Discourse. Se è così, il problema è che il nonce generato da WordPress è scaduto. Questo accade sui siti WordPress che hanno una cache degli oggetti abilitata.
Una soluzione è disabilitare la cache degli oggetti in qualsiasi pagina che abbia il link “Accedi con Discourse”. Per questo approccio, assicurati che la cache degli oggetti sia disabilitata per gli utenti anonimi.
Un’altra soluzione è descritta qui: Wordpress SSO Expired nonce - #15 by simon. La funzione in quel post può essere copiata esattamente com’è nel file functions.php del tuo tema WordPress.
Quella funzione aggiunge una stringa casuale all’URL di Accedi con Discourse. La stringa casuale attiva WordPress a interrompere la cache e generare un nuovo nonce per l’utente. @angus, questo dovrebbe probabilmente essere aggiunto al codice del plugin: wp-discourse/lib/sso-client/sso-client-base.php at main · discourse/wp-discourse · GitHub. Non ci sono svantaggi e non credo ci sia un altro modo per gestire la cache degli oggetti che causa l’utilizzo di nonce obsoleti invece di generarne di nuovi per ogni visita.
3 Mi Piace
Grazie mille per la risposta. Una volta avviato Discourse in produzione, proveremo a disabilitare la cache Nging sul sito WordPress e se ciò non dovesse funzionare modificheremo il file functions.php secondo le istruzioni.
Grazie @simon!
Non mi è molto chiaro perché questo dovrebbe cancellare la cache degli oggetti di WordPress, poiché tipicamente l’aggiunta di una stringa casuale a un URL viene utilizzata per evitare la cache del browser. Quale query viene memorizzata nella cache degli oggetti di WordPress? Vedo un motivo non legato alla cache degli oggetti per cui tale approccio potrebbe funzionare
Tuttavia, se questo è il caso, potremmo aver bisogno di una modifica leggermente diversa. Ma forse mi sfugge qualcosa?
Il problema non riguarda la cache degli oggetti di WordPress, per quanto ne so non è persistente tra le richieste. Il problema si verifica con siti che hanno una qualche forma di cache persistente: https://developer.wordpress.org/reference/classes/wp_object_cache/#persistent-caching. Questa può essere configurata tramite un plugin, ma è anche abilitata per impostazione predefinita da alcuni provider di hosting, ad esempio WP Engine. Penso che nel caso di WP Engine, non abilitino la cache degli oggetti sulla loro pagina di accesso, ma la abilitino per gli utenti anonimi su tutte le altre pagine. Quindi su WP Engine il problema viene attivato solo se il link “login with Discourse” viene aggiunto a una pagina diversa dalla pagina di accesso.
Il problema con discourse_sso_url è che quando è sempre impostato sullo stesso valore, per i siti che hanno una cache persistente abilitata, restituirà sempre lo stesso nonce. Impostare il suo valore discourse_sso su una stringa casuale, invece di impostarlo sul suo valore predefinito di 1, interrompe la cache. Almeno ha sempre funzionato in quel modo quando l’ho testato in precedenza. Al momento non ho le cose configurate per testarlo.
Modifica: ci sono alcuni dettagli in più sul problema qui: Discourse (as provider) + WP SSO nonce error - #14 by simon. È passato un bel po’ di tempo da quando l’ho esaminato. La soluzione al problema all’epoca sembrava essere quella di entrambe aggiungere una stringa casuale a discourse_sso_url e assicurarsi che la cache della pagina non fosse abilitata sulla pagina in cui veniva visualizzato il link di accesso (altrimenti, la stringa casuale non sarà univoca per ogni visita di un utente anonimo).
Capisco. Grazie per la spiegazione.
Penso che dovremmo procedere un passo alla volta, poiché sono cauto nel proporre una correzione qui senza essere sicuro che sia “pluralistica”, cioè che funzioni con diversi approcci di caching.
Inoltre, non mi è ancora del tutto chiaro il ruolo delle varie cache nel causare questo specifico problema, in particolare i ruoli diversi della cache degli oggetti persistenti e della cache delle pagine (se presenti). Posso capire perché una cache delle pagine potrebbe causare questo problema, ma non una cache degli oggetti persistenti (ancora). Se si tratta di quest’ultima, potremmo voler modificare le query nella nostra classe Nonce.
Dovrò testare questo aspetto più a fondo la prossima settimana.
@Petr_Mišák Potresti prima provare a disabilitare qualsiasi caching di pagina che hai sulla pagina con il link di accesso e farci sapere come va?
Proverò a disabilitare la nostra Nginx Microcache per una pagina di test di accesso su WordPress. La nostra pagina di test in cui accediamo a WordPress tramite Discourse è qui Test Discourse Login | Svět Androida
Ho (occasionalmente) notato il problema se uso l’accesso Google per accedere.
Ma ora sono sorpreso che i collegamenti di accesso a Discourse che abbiamo inserito nella pagina utilizzando lo shortcode siano scomparsi dalla nostra pagina di test.
Qualcuno ha idea del perché stia succedendo questo?
Finché non risolvo il problema con la pagina di accesso di test, non ho alcun “nonce scaduto” da testare.
Prima assicurati che non ci sia qualche problema di cache. Facci sapere come procede.
Capisco, lo risolveremo passo dopo passo, sono d’accordo.
Sembra che l’errore si verifichi anche con il login ufficiale. Ecco un’email per simularlo in modo che tu possa provarlo tu stesso.
- vai alla pagina Přihlásit se ‹ Svět Androida — WordPress
- accedi utilizzando “Accedi con Discourse” e utilizza il tuo account Google lì
- dopo aver effettuato l’accesso a Discourse, verrai reindirizzato nuovamente a https://www.svetandroida.cz/ o https://www.svetandroida.cz/wp-login.php con un messaggio di errore, vedi screenshot.
È testato male perché il problema non si presenta sempre.
Per favore, prova e fammi sapere se riscontri l’errore prima che disabiliti la cache di Nginx. Grazie
1 Mi Piace
Ho controllato lo stato del nostro Nginx Microcache su Přihlásit se ‹ Svět Androida — WordPress, ma sembra che Nginx Microcache non venga affatto utilizzato lì. Il problema con il “nonce scaduto” sarà quindi correlato a qualcos’altro.
1 Mi Piace
Ciao @Petr_Mišák, volevo solo sapere se sei riuscito a trovare il colpevole?
Abbiamo cercato ma finora, purtroppo, senza successo. Continueremo però a cercare e a indagare sulla causa del problema.
Sono abbastanza sicuro che il problema di accesso a https://www.svetandroida.cz/ tramite Discourse sia correlato alla cache del nonce. Il modo in cui l’ho testato è stato cliccando sul link “Accedi con Discourse” (https://www.svetandroida.cz/?discourse_sso=1&redirect_to=https%3A%2F%2Fwww.svetandroida.cz%2F).
La prima volta che l’ho fatto, sono stato reindirizzato a https://komunita.svetandroida.cz/, ho creato un account sul sito Discourse con Gmail, quindi sono stato reindirizzato nuovamente al tuo sito WordPress come utente connesso.
Successivamente, ho effettuato il logout dal tuo sito WordPress e ho provato ad accedere nuovamente cliccando sul link “Accedi con Discourse”. Questa volta ho ricevuto l’errore “nonce scaduto”.
Ho quindi generato un link di accesso con un valore casuale per il parametro URL discourse_sso, ad esempio https://www.svetandroida.cz/?discourse_sso=181253058&redirect_to=https%3A%2F%2Fwww.svetandroida.cz%2F e sono stato in grado di accedere al tuo sito WordPress tramite Discourse senza problemi.
Ho provato questo un paio di volte, sia con il link di accesso generato dal plugin (https://www.svetandroida.cz/?discourse_sso=1&redirect_to=https%3A%2F%2Fwww.svetandroida.cz%2F) sia con link di accesso che hanno un valore casuale impostato per il parametro discourse_sso. Sembra che il nonce restituito venga memorizzato nella cache per almeno qualche minuto.
Senza eseguire il debug completo del problema, sono abbastanza sicuro che le cose funzioneranno semplicemente aggiungendo quanto segue al file functions.php del tuo tema (imposterà una stringa casuale al parametro URL discourse_sso. Questo dovrebbe funzionare finché non è abilitata anche la “cache della pagina” sulla tua pagina di accesso.)
add_filter('wpdc_sso_client_query', 'wpdc_custom_sso_client_query' );
function wpdc_custom_sso_client_query() {
return wp_generate_password( 12, false );
}
Se desideri eseguire il debug del problema, ecco cosa vedo per una richiesta riuscita. Nota la riga Cache-Svetzitrka: STALE. Questo potrebbe indicare che è in atto uno strato di caching personalizzato e che la cache era STALE per la richiesta riuscita (quindi è stato generato un nuovo nonce.)
Riepilogo
Request URL:
https://www.svetandroida.cz/?discourse_sso=1&redirect_to=https%3A%2F%2Fwww.svetandroida.cz%2F
Request Method:
GET
Status Code:
302 Found
Remote Address:
93.185.102.156:443
Referrer Policy:
strict-origin-when-cross-origin
Cache-Control:
max-age=0
Cache-Svetzitrka:
STALE
Content-Length:
0
Content-Type:
text/html; charset=UTF-8
Date:
Mon, 11 Dec 2023 09:38:05 GMT
Expires:
Mon, 11 Dec 2023 09:21:47 GMT
Location:
https://komunita.svetandroida.cz/session/sso_provider?sso=bm9uY2U9MGU3NTNjYWNhNjMwNmMzNzM5M2MyODk4MjZlYzMxMjQmcmV0dXJuX3Nzb191cmw9aHR0cHMlM0ElMkYlMkZ3d3cuc3ZldGFuZHJvaWRhLmN6JTJG&sig=32ddcc85bd2dd7175f963e791cc9ac734a607355d773422d3abec6173c9f656b
Server:
nginx
Strict-Transport-Security:
max-age=10886400; includeSubdomains; preload
X-Content-Type-Options:
nosniff
X-Frame-Options:
SAMEORIGIN
X-Redirect-By:
WordPress
Ecco cosa vedo per una richiesta fallita. La riga Cache-Control: no-cache, no-store sembra indicare che la risposta non dovrebbe essere memorizzata nella cache, ma la voce from service worker nella risposta indica che la risposta potrebbe provenire dalla cache di un service worker.
Riepilogo
Request URL:
https://www.svetandroida.cz/?discourse_sso=1&redirect_to=https%3A%2F%2Fwww.svetandroida.cz%2F
Request Method:
GET
Status Code:
302 Found (from service worker)
Referrer Policy:
strict-origin-when-cross-origin
Cache-Control:
no-cache, no-store
Content-Security-Policy:
upgrade-insecure-requests; base-uri 'self'; object-src 'none'; script-src https://komunita.svetandroida.cz/logs/ https://komunita.svetandroida.cz/sidekiq/ https://komunita.svetandroida.cz/mini-profiler-resources/ https://komunita.svetandroida.cz/assets/ https://komunita.svetandroida.cz/extra-locales/ https://komunita.svetandroida.cz/highlight-js/ https://komunita.svetandroida.cz/javascripts/ https://komunita.svetandroida.cz/plugins/ https://komunita.svetandroida.cz/theme-javascripts/ https://komunita.svetandroida.cz/svg-sprite/ https://www.google-analytics.com/analytics.js https://www.googletagmanager.com/gtag/js 'sha256-8uAKDaK4QxxCeYZl0Wxad2Nnj2tgKyA14hYBh66pnn0='; worker-src 'self' https://komunita.svetandroida.cz/assets/ https://komunita.svetandroida.cz/javascripts/ https://komunita.svetandroida.cz/plugins/; frame-ancestors 'self'; manifest-src 'self'
Content-Type:
text/html; charset=utf-8
Date:
Mon, 11 Dec 2023 09:38:05 GMT
Discourse-Logged-Out:
1
Location:
https://komunita.svetandroida.cz/login
Referrer-Policy:
strict-origin-when-cross-origin
Server:
nginx
Set-Cookie:
sso_payload=sso%3Dbm9uY2U9MGU3NTNjYWNhNjMwNmMzNzM5M2MyODk4MjZlYzMxMjQmcmV0dXJuX3Nzb191cmw9aHR0cHMlM0ElMkYlMkZ3d3cuc3ZldGFuZHJvaWRhLmN6JTJG&sig=32ddcc85bd2dd7175f963e791cc9ac734a607355d773422d3abec6173c9f656b; path=/; SameSite=Lax
Set-Cookie:
_forum_session=kGW2K6gafsjS90qQMEmxzjggEYo4tZPZe76XZNVro34ilyuuHsaYt2nEzC9h6tfiSBmY9XoDdxh1SV3S8n%2BwqrbsD58UvJBz6khjm%2Fty83ufkgry8daHDdyoTfFwQOjAbXrWeGIwkS4edGY1XetNwXhu%2FNJUghqmq8BEUycBt7098KUO%2BmRYDl5iSL0FNhUzo5Hc7xwRg0tfxuxmb%2FIyVLnbFz6IJuGB3Y95PRcU5DYIwAAny1GQbKQ23kSjgALxAThG7aA%2B7LCI9cJNWV1JRSy%2FTElDN3iugKuVpaQcrSPhV3SvQaiNH3MCfLwu6yxlp%2BZ%2BwTyw22czX8bb197z36WhlbghYtxvKYGRjONJQUagisjPpMrCAcGeTKsGB4JgnUKCtlrwIoFvaDxjec7hMo3aCnibbbkmcxWc6LvD6G2xaxkDgebe7RpvfTYdG8cn8j6rNwX3hM8la4RqZnmma0%2FQlSrfj0BjfY7lnan6TYm28vLwH%2FFfdZoRbo6JdTs5AFjCJvx9UXSjFmoXHH1R1yfAizPeKDFnpiuUs4a%2FBzWafQ%3D%3D--8PEvbWwpqBuJMSRJ--CzzhBea4mmv58a7KLEnukw%3D%3D; path=/; secure; HttpOnly; SameSite=Lax
Set-Cookie:
_t=; path=/; max-age=0; expires=Thu, 01 Jan 1970 00:00:00 GMT; SameSite=Lax
Strict-Transport-Security:
max-age=31536000
Vary:
Accept
X-Content-Type-Options:
nosniff
X-Discourse-Route:
session/sso_provider
X-Download-Options:
noopen
X-Frame-Options:
SAMEORIGIN
X-Permitted-Cross-Domain-Policies:
none
X-Request-Id:
001750b9-94f2-4bf0-8503-9d673463b91e
X-Runtime:
0.012335
X-Xss-Protection:
0
2 Mi Piace