Ich bin auf das gleiche Problem gestoßen und es tritt auch beim Anmelden mit Google auf. Vor WordPress verwenden wir Nginx als Reverse-Proxy. Könnte das damit zusammenhängen?
Ich gehe davon aus, dass dies beim Anmelden bei WordPress über Ihre Discourse-Site geschieht. Wenn dies der Fall ist, liegt das Problem darin, dass die von WordPress generierte Nonce abgelaufen ist. Dies geschieht auf WordPress-Sites, auf denen ein Objekt-Cache aktiviert ist.
Eine Lösung besteht darin, den Objekt-Cache auf allen Seiten zu deaktivieren, auf denen sich der Link „Mit Discourse anmelden“ befindet. Stellen Sie bei diesem Ansatz sicher, dass der Objekt-Cache für anonyme Benutzer deaktiviert ist.
Eine weitere Lösung wird hier beschrieben: Wordpress SSO Expired nonce - #15 by simon. Die Funktion in diesem Beitrag kann genau so in die functions.php-Datei Ihres WordPress-Themes kopiert werden.
Diese Funktion fügt der URL „Mit Discourse anmelden“ eine zufällige Zeichenfolge hinzu. Die zufällige Zeichenfolge veranlasst WordPress, den Cache zu leeren und eine neue Nonce für den Benutzer zu generieren. @angus, dies sollte wahrscheinlich in den Code des Plugins aufgenommen werden: wp-discourse/lib/sso-client/sso-client-base.php at main · discourse/wp-discourse · GitHub. Es gibt keine Nachteile, und ich glaube nicht, dass es eine andere Möglichkeit gibt, mit Objekt-Caching umzugehen, das veraltete Nonces verwendet, anstatt für jeden Besuch neue zu generieren.
3 „Gefällt mir“
Vielen Dank für die Antwort. Sobald wir Discourse in den Live-Betrieb nehmen, werden wir versuchen, den Nging-Cache auf der WordPress-Seite zu deaktivieren, und wenn das nicht funktioniert, werden wir die functions.php gemäß den Anweisungen bearbeiten.
Danke @simon!
Ich bin mir nicht ganz sicher, warum dies den Objekt-Cache von WordPress leeren würde, da das Hinzufügen eines zufälligen Strings zu einer URL normalerweise dazu dient, den Cache des Browsers zu umgehen. Welche Abfrage wird im Objekt-Cache von WordPress gecacht? Ich sehe einen Grund, der nichts mit dem Objekt-Cache zu tun hat, warum dieser Ansatz funktionieren könnte.
Wenn das der Fall ist, benötigen wir möglicherweise eine leicht andere Anpassung. Aber vielleicht übersehe ich etwas?
Das Problem liegt meines Wissens nicht beim WordPress-Objekt-Cache, da dieser nicht über Anfragen hinweg persistent ist. Das Problem tritt bei Websites auf, die eine Art persistenten Cache haben: https://developer.wordpress.org/reference/classes/wp_object_cache/#persistent-caching. Dies kann über ein Plugin konfiguriert werden, ist aber auch standardmäßig bei einigen Hosting-Anbietern aktiviert, z. B. bei WP Engine. Ich denke, im Fall von WP Engine aktivieren sie den Objekt-Cache nicht auf ihrer Anmeldeseite, aber sie aktivieren ihn für anonyme Benutzer auf allen anderen Seiten. Bei WP Engine wird das Problem also nur ausgelöst, wenn der Link „Mit Discourse anmelden“ auf einer anderen Seite als der Anmeldeseite hinzugefügt wird.
Das Problem mit der discourse_sso_url besteht darin, dass sie, wenn sie immer auf denselben Wert gesetzt ist, bei Websites mit aktiviertem persistentem Cache immer denselben Nonce zurückgibt. Das Setzen seines discourse_sso-Werts auf eine zufällige Zeichenfolge anstelle seines Standardwerts 1 bricht den Cache. Zumindest hat es bisher immer so funktioniert, wenn ich es getestet habe. Ich habe derzeit keine Möglichkeit, es zu testen.
Bearbeiten: Hier gibt es weitere Details zum Problem: Discourse (as provider) + WP SSO nonce error - #14 by simon. Es ist schon eine Weile her, seit ich mir das angesehen habe. Die damalige Lösung für das Problem schien zu sein, sowohl eine zufällige Zeichenfolge zur discourse_sso_url hinzuzufügen als auch sicherzustellen, dass das Seiten-Caching auf der Seite, auf der der Anmeldelink angezeigt wurde, nicht aktiviert war (andernfalls wäre die zufällige Zeichenfolge bei jedem Besuch eines anonymen Benutzers nicht eindeutig).
Ich verstehe. Danke für die Erklärung.
Ich denke, wir sollten das Schritt für Schritt angehen, da ich befürchte, eine Korrektur hier voranzutreiben, ohne sicher zu sein, dass sie „pluralistisch“ ist, d. h. dass sie mit verschiedenen Caching-Ansätzen funktioniert.
Mir ist auch noch nicht ganz klar, welche Rolle die verschiedenen Caches bei der Verursachung dieses spezifischen Problems spielen, insbesondere die unterschiedlichen Rollen von persistenten Objekt- und Seitencaches (falls vorhanden). Ich kann verstehen, warum ein Seitencache dieses Problem verursachen könnte, aber (noch) kein persistenter Objektcache. Wenn es letzteres ist, möchten wir vielleicht die Abfragen in unserer Nonce-Klasse anpassen.
Ich muss das nächste Woche noch etwas genauer testen.
@Petr_Mišák Könnten Sie bitte zuerst versuchen, jegliches Seitencaching auf der Seite mit dem Anmeldelink zu deaktivieren und uns mitteilen, wie es Ihnen damit ergeht?
Ich werde versuchen, unseren Nginx Microcache für eine Test-Login-Seite auf WordPress zu deaktivieren. Unsere Testseite, auf der wir uns über Discourse bei WordPress anmelden, finden Sie hier Test Discourse Login | Svět Androida
Ich habe das Problem (gelegentlich) bemerkt, wenn ich mich über Google-Login anmelde.
Aber jetzt bin ich überrascht, dass die Discourse-Login-Links, die wir mit dem Shortcode auf der Seite platziert haben, von unserer Testseite verschwunden sind.
Hat jemand eine Idee, warum das passiert?
Bis ich das Problem mit der Test-Login-Seite gelöst habe, habe ich keinen „abgelaufenen Nonce“, um es zu testen.
Bitte stellen Sie zunächst sicher, dass es sich nicht um ein Caching-Problem handelt. Teilen Sie uns mit, wie Sie damit vorgehen.
Ich verstehe, wir werden es Schritt für Schritt lösen, ich stimme zu.
Es scheint, dass der Fehler auch bei der offiziellen Anmeldung auftritt. Hier ist eine E-Mail, um ihn zu simulieren, damit Sie es selbst versuchen können.
- Gehen Sie zur Seite Přihlásit se ‹ Svět Androida — WordPress
- Melden Sie sich mit „Mit Discourse anmelden“ an und verwenden Sie dort Ihr Google-Konto
- Nach der Anmeldung bei Discourse werden Sie mit einer Fehlermeldung zurück zu https://www.svetandroida.cz/ oder https://www.svetandroida.cz/wp-login.php weitergeleitet, siehe Screenshot.
Es ist schlecht getestet, da das Problem nicht immer auftritt.
Bitte versuchen Sie es und lassen Sie mich wissen, ob Sie den Fehler erhalten, bevor ich den Nginx-Cache deaktiviere. Danke
1 „Gefällt mir“
Ich habe den Status unseres Nginx Microcache unter Přihlásit se ‹ Svět Androida — WordPress überprüft, aber es scheint, dass Nginx Microcache dort überhaupt nicht verwendet wird. Das Problem mit dem „abgelaufenen Nonce“ wird daher mit etwas anderem zusammenhängen.
1 „Gefällt mir“
Hallo @Petr_Mišák, ich wollte nur nachfragen, ob Sie den Schuldigen dafür gefunden haben?
Wir haben gesucht, aber bisher leider ohne Erfolg. Wir werden aber weiter suchen und nach der Ursache des Problems forschen.
Ich bin ziemlich sicher, dass das Problem mit der Anmeldung bei https://www.svetandroida.cz/ über Discourse mit dem zwischengespeicherten Nonce zusammenhängt. Ich habe dies getestet, indem ich auf den Link “Mit Discourse anmelden” geklickt habe (https://www.svetandroida.cz/?discourse_sso=1&redirect_to=https%3A%2F%2Fwww.svetandroida.cz%2F).
Beim ersten Mal wurde ich zu https://komunita.svetandroida.cz/ weitergeleitet, habe ein Konto auf der Discourse-Website mit Gmail erstellt und wurde dann als angemeldeter Benutzer zu Ihrer WordPress-Website zurückgeleitet.
Ich habe mich dann von Ihrer WordPress-Website abgemeldet und versucht, mich erneut anzumelden, indem ich auf den Link “Mit Discourse anmelden” geklickt habe. Dieses Mal erhielt ich die Fehlermeldung “Nonce abgelaufen”.
Ich habe dann einen Anmeldelink mit einem zufälligen Wert für den URL-Parameter discourse_sso generiert, z. B. https://www.svetandroida.cz/?discourse_sso=181253058&redirect_to=https%3A%2F%2Fwww.svetandroida.cz%2F und konnte mich ohne Probleme über Discourse bei Ihrer WordPress-Website anmelden.
Ich habe dies mehrmals versucht, sowohl mit dem vom Plugin generierten Anmeldelink (https://www.svetandroida.cz/?discourse_sso=1&redirect_to=https%3A%2F%2Fwww.svetandroida.cz%2F) als auch mit Anmelde-Links, bei denen der discourse_sso-Parameter einen zufälligen Wert hat. Es scheint, dass der zurückgegebene Nonce für mindestens einige Minuten zwischengespeichert wird.
Ohne das Problem vollständig zu debuggen, bin ich ziemlich sicher, dass Sie die Dinge zum Laufen bringen können, indem Sie einfach Folgendes zu Ihrer functions.php-Datei hinzufügen (es wird ein zufälliger String für den discourse_sso-URL-Parameter festgelegt. Dies sollte funktionieren, solange auf Ihrer Anmeldeseite keine “Seiten-Caching” aktiviert ist.)
add_filter('wpdc_sso_client_query', 'wpdc_custom_sso_client_query' );
function wpdc_custom_sso_client_query() {
return wp_generate_password( 12, false );
}
Wenn Sie das Problem debuggen möchten, sehen Sie hier, was ich bei einer erfolgreichen Anfrage sehe. Beachten Sie die Zeile Cache-Svetzitrka: STALE. Dies könnte darauf hindeuten, dass eine benutzerdefinierte Caching-Schicht vorhanden ist und der Cache für die erfolgreiche Anfrage STALE war (sodass ein neuer Nonce generiert wurde.)
Zusammenfassung
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
Hier ist, was ich bei einer fehlgeschlagenen Anfrage sehe. Die Zeile Cache-Control: no-cache, no-store scheint darauf hinzudeuten, dass die Antwort nicht zwischengespeichert werden sollte, aber der Eintrag from service worker in der Antwort deutet darauf hin, dass die Antwort aus dem Cache eines Service Workers stammen könnte.
Zusammenfassung
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%26sig%3D32ddcc85bd2dd7175f963e791cc9ac734a607355d773422d3abec6173c9f656b; 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 „Gefällt mir“