Ist das das Einzige, was diese Einstellung bewirkt?
Ich finde, sie ist in WP ziemlich vage benannt und beschrieben, daher habe ich mich gefragt, was sie sonst noch tun könnte?
Ist das das Einzige, was diese Einstellung bewirkt?
Ich finde, sie ist in WP ziemlich vage benannt und beschrieben, daher habe ich mich gefragt, was sie sonst noch tun könnte?
Diesbezüglich,
was ist, wenn ein Benutzer bereits in WordPress und Discourse existiert? Wie kann ich deren Profile zusammenführen/verknüpfen?
Technisch gesehen ruft es die Discourse sync_sso-Route auf und übergibt deren Daten (WordPress user_id, Benutzername, Name, E-Mail usw.) unmittelbar nach dem Login in WordPress an Discourse. Details zur sync_sso-Route finden Sie hier: Sync DiscourseConnect user data with the sync_sso route.
Die einzige Nebenwirkung, die mir für WordPress-Benutzer bekannt ist, die die Discourse-Website noch nie besucht haben, ist, dass sie Digest-E-Mails von Discourse erhalten.
Deshalb möchten Sie Ihre Discourse-Benutzer ermutigen, sich bei WordPress mit derselben E-Mail-Adresse zu registrieren, die sie auch bei Discourse verwenden. Solange die E-Mail-Adressen übereinstimmen, werden sie beim richtigen Discourse-Konto angemeldet. Dies setzt voraus, dass Sie sich um das Problem mit der E-Mail-Verifizierung kümmern, das wir in früheren Beiträgen besprochen haben.
Es ist wahrscheinlich, dass einige Benutzer sich bei WordPress mit anderen E-Mail-Adressen anmelden, als sie sie bei Discourse verwendet haben. In diesem Fall wird für sie ein neues Discourse-Konto erstellt, das die WordPress-E-Mail-Adresse verwendet. Sie müssen das alte Discourse-Konto manuell mit dem neuen Discourse-Konto zusammenführen: Merging user accounts.
Was passiert, wenn wir die E-Mail eines Benutzers manuell in WordPress aktualisieren müssen? Wird ihre Discourse-E-Mail ebenfalls aktualisiert, wenn diese Einstellung aktiviert ist?
Das Aktualisieren eines Benutzers von seiner WordPress-Profilseite aus löst nicht den Aufruf von sync_sso aus. Das sollte es wahrscheinlich aber tun. Vorerst müssen Sie ihn bitten, sich aus WordPress abzumelden und sich dann wieder bei WordPress anzumelden. Ich glaube nicht, dass es für einen Administrator möglich ist, einen WordPress-Benutzer von seiner Profilseite aus abzumelden.
Wenn Sie E-Mails und/oder Benutzernamen zwischen WordPress und Discourse synchron halten möchten, aktivieren Sie diese Discourse-Einstellungen:
auth overrides emailauth overrides usernameDanke Simon. Ich denke, dies ist der Prozess, den ich nach Abwägung aller Umstände wählen werde:
Was neue Anmeldungen betrifft, muss ich einen Weg finden, die E-Mails zu verifizieren. Ich werde ihnen wahrscheinlich ihre Passwörter per E-Mail zusenden.
Ich habe auch festgestellt, dass der Benutzer sich immer noch über SSO bei Discourse anmelden kann, auch wenn die Einstellung „E-Mail-Adresse verifiziert“ im WordPress-Profil nicht ausgewählt ist. Sie müssen ihre E-Mail jedoch bei der ersten Eingabe von Discourse bestätigen. Das ist gut.
Haben diese Einstellungen irgendwelche Nebenwirkungen?
Ja, das ist so vorgesehen. Das ist für die meisten Benutzer keine große Hürde. Das Problem, das Sie beachten müssen, ist, dass Discourse Benutzer nicht anhand ihrer E-Mail-Adresse abgleicht, wenn die E-Mail-Adresse in WordPress nicht als verifiziert markiert ist, wenn sie sich zum ersten Mal über DiscourseConnect bei Discourse anmelden. Solange Sie einen Weg finden, die E-Mail-Adressen Ihrer importierten Benutzer als verifiziert zu markieren, wird dies kein Problem darstellen. Wenn Sie sie nicht als verifiziert markieren, wird es schwierig, die Dinge zu klären.
Wenn sie aktiviert sind, verhindern sie, dass Benutzer ihren Benutzernamen oder ihre E-Mail-Adresse auf Discourse ändern.
Ja, ich habe viel getestet und das festgestellt. Ich werde einfach ein benutzerdefiniertes Skript schreiben, das alle Benutzer, die ich importiere, als verifiziert markiert.
Danke für die Klärung!
Ist es in Ordnung, die ausführliche Protokollierung (/logs) dauerhaft zu aktivieren?
Wird sich dies negativ auf die Leistung auswirken?
Ich habe Fälle gesehen, in denen sie für immer eingeschaltet blieben. Ich glaube nicht, dass dies einen nennenswerten Einfluss auf die Leistung hat. Es vermüllt nur Ihre Protokolle, wenn Sie versuchen, ein Problem zu beheben, das nichts mit DiscourseConnect zu tun hat.
Bisher hat alles super funktioniert!
Eine Kleinigkeit, die mir auffällt, ist, dass jeder Pfad, den ich in dieses Feld eingebe:
zur Standard-WordPress-Anmeldeseite wird.
Wenn ich zum Beispiel jetzt versuche, zu /wp-admin zu gehen, was ich zuvor zum Anmelden als Administrator verwendet habe, werde ich zu /login/forum weitergeleitet.
Idealerweise würde dies nur dann zu dieser Seite weiterleiten, wenn jemand auf die Anmeldeschaltfläche des Discourse-Forums klickt.
Ich frage mich, ob dies normales Verhalten ist und ob es schlecht ist, dass es so funktioniert.
Das ist das erwartete Verhalten. Die Option „Pfad zu Ihrer Anmeldeseite“ wird verwendet, um den Standard-WordPress-Anmeldepfad zu überschreiben. Dies geschieht durch Einhaken in den WordPress-Filter login_url.
Die Standard-Loginroute unter /wp-login.php wird dadurch nicht entfernt, sodass Sie diese URL immer noch direkt aufrufen können, indem Sie sie in die Adressleiste Ihres Browsers eingeben. Anstatt zu /wp-admin zu gehen, rufen Sie /wp-login.php auf, um die Standard-Loginseite zu verwenden.
Mir fällt eine Möglichkeit ein, wie das Plugin aktualisiert werden könnte, um nur zu dem Pfad „Pfad zu Ihrer Anmeldeseite“ für die Anmeldung bei Discourse weiterzuleiten, aber diese Änderung würde etwas Arbeit erfordern.
Kein Problem. Nur eine Kleinigkeit. Danke für die Einblicke!
Hallo @simon, ich sehe die folgenden Fehler in meinen Protokollen und frage mich, was sie bedeuten und wie ich sie beheben kann. Mir sind diese Fehler aufgefallen, nachdem ein Benutzer sagte, er erhalte eine Fehlermeldung beim Versuch, sich anzumelden.
(google_oauth2) Authentifizierungsfehler! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF erkannt
Authentifizierungsfehler! request_error: OAuth::Unauthorized, 401 Unauthorized
(facebook) Authentifizierungsfehler! no_authorization_code: OmniAuth::Strategies::Facebook::NoAuthorizationCodeError, muss entweder ein code (entweder über die URL oder über einen signierten fbsr_XXX-Cookie) übergeben werden.
Es ist erwähnenswert, dass diese Fehler nicht häufig auftreten. Die meisten Protokolle scheinen erfolgreich zu funktionieren:
Ich habe gerade diesen Screenshot vom Benutzer erhalten:
Er sagte: „Es gibt keine E-Mail. Sobald Sie auf den Anmeldelink klicken, wird Ihnen die folgende Seite angezeigt…“
Wenn ich auf den Login-/Anmeldelink klicke (im Inkognito-Modus), funktioniert es bei mir.
Hier ist die URL zu unserem Forum als Referenz: forum.projectvanlife.com
Ich gehe davon aus, dass die Einträge, die mit „Verbose SSO log“ beginnen, erfolgreiche Anmeldungen anzeigen.
Bei den Fehlern „google_oauth2“, „OAuth::Unauthorized“ und „facebook“ bin ich mir nicht sicher, was vor sich geht. War Ihre Discourse-Site zuvor so konfiguriert, dass Benutzer sich über Google und Facebook anmelden konnten? Wenn ja, können sie sich jetzt nicht mehr über diese Methoden auf der Website anmelden, da DiscourseConnect aktiviert ist. Versuchen Sie vielleicht, Google- und Facebook-Anmeldungen auf Ihrer Discourse-Einstellungsseite zu deaktivieren.
Versuchen Sie für Benutzer, die Anmeldeprobleme melden, eine ausführliche SSO-Protokollfehlermeldung zu finden, die mit dem Anmeldeversuch des Benutzers verknüpft ist. Sehen Sie dann nach, ob der Fehler mit einem der Probleme übereinstimmt, die in diesem Thema beschrieben sind: Debug and fixing common DiscourseConnect issues.
Die in der Adressleiste des Browsers angezeigte URL lautet https://projectvanlife.com/login/forum/javascript%3Avoid(0.
Ich gehe davon aus, dass ein Teil des Javascript abgeschnitten wird und es tatsächlich so dekodiert werden soll, dass es javascript:void(0) ergibt. Ich bin mir nicht sicher, woher das kommen könnte. Möglicherweise von einer der Browser-Erweiterungen des Benutzers. Versuchen Sie, ihn aufzufordern, seine Browser-Erweiterungen zu deaktivieren oder zu versuchen, sich in einem Inkognito-Fenster anzumelden.
Bearbeitung: @Sami_Syed Der Code javascript:void(0) wird an den Pfad angehängt, wenn auf den Link „Registrieren“ der Anmeldeseite geklickt wird. Das href-Element dieses Links lautet: \"javascript%3Avoid(0)\"
Ich vermute, dass dies dazu dient, das Registrierungsformular auf demselben Pfad wie das Anmeldeformular zu haben. Irgendetwas geht damit jedoch schief. Wissen Sie, ob dies vor der Aktivierung von DiscourseConnect korrekt funktioniert hat?
Wenn das Plugin, das für die Anmelde-/Registrierungsformulare verwendet wird, eine Option hat, das Registrierungsformular auf einer separaten Seite anzuzeigen, sollte die Aktivierung dieser Option als schnelle Lösung für das Problem dienen.
Ich werde heute den größten Teil des Tages offline sein, kann aber später versuchen, Ihnen bei diesem Problem zu helfen, wenn Sie nicht weiterkommen.
Bearbeitung: Ich war darüber verwundert, also habe ich es mir noch einmal angesehen. Der Tab „Registrieren“ im Anmeldeformular funktioniert ohne Probleme. Der Link „Registrieren“ weist das von mir beschriebene Problem auf:
Die schnelle Lösung für das Problem besteht also darin, einfach den Link zum Registrieren zu entfernen.
Das ist korrekt.
Ja, das war aktiviert. Die Frage ist jedoch, wie können sie sich überhaupt über FB oder Google anmelden? Unsere aktuelle Anmeldeseite hat diese Funktion nicht.
Oder tritt dieser Fehler bei denen auf, die sich ursprünglich mit G oder FB angemeldet haben und sich jetzt anmelden möchten, es aber nicht funktioniert?
Und wenn das der Fall ist, wie kann ich das beheben?
Wie ich sehe, liegt es daran, dass ich dort keinen korrekten Link angegeben habe. Ups. Guter Fang und danke!
Ich weiß nicht, was es auslösen könnte. Vielleicht wurde die URL zum Authentifizierungsanbieter vom Browser des Benutzers zwischengespeichert. Das ist aber nur eine Vermutung.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.