この設定はこれだけしか行わないのでしょうか？
WPでの名前と説明がかなり曖昧だと感じるので、他に何をする可能性があるのか疑問に思っていました。
これに関して、
ユーザーがWordPressとDiscourseの両方に既に存在する場合はどうなりますか？プロファイルをマージ/接続するにはどうすればよいですか？
技術的には、Discourseのsync_ssoルートを呼び出し、WordPressにログインした直後にDiscourseにデータ（WordPressのuser_id、username、name、emailなど）を渡します。sync_ssoルートの詳細はこちらをご覧ください：https://meta.discourse.org/t/sync-discourseconnect-user-data-with-the-sync-sso-route/84398。
私が知る限り、これによる唯一の副作用は、Discourseサイトを一度も訪れたことのないWordPressユーザーがDiscourseからダイジェストメールを受け取り始めることです。
そのため、Discourseユーザーには、Discourseで使用しているのと同じメールアドレスでWordPressに登録するように促す必要があります。メールアドレスが一致していれば、正しいDiscourseアカウントにログインされます。これは、以前の投稿で議論したメール検証の問題に対処していることを前提としています。
WordPressでDiscourseとは異なるメールアドレスでサインアップするユーザーも出てくる可能性が高いです。その場合、WordPressのメールアドレスを使用して新しいDiscourseアカウントが作成されます。古いDiscourseアカウントを新しいDiscourseアカウントに手動でマージする必要があります：https://meta.discourse.org/t/merge-user-accounts/275288。
「いいね！」 3
この設定が有効になっている場合、WordPressでユーザーのメールアドレスを手動で更新する必要がある場合、Discourseのメールアドレスも更新されますか？
「いいね！」 1
WordPressのプロフィールページからユーザーを更新しても、sync_ssoの呼び出しはトリガーされません。おそらくトリガーされるべきでしょう。今のところ、ユーザーにWordPressからログアウトしてもらい、再度WordPressにログインしてもらう必要があります。管理者がプロフィールページからWordPressユーザーをログアウトさせることはできないと思われます。
WordPressとDiscourse間でメールアドレスやユーザー名を同期させたい場合は、これらのDiscourse設定を有効にしてください。
auth overrides emailauth overrides username
「いいね！」 1
サイモンさん、ありがとうございます。あらゆることを考慮した上で、このプロセスで進めようと思います。
- Discourseからユーザーをエクスポートする
- Discourse Connectを有効にする
- WordPressにそれらのユーザーをインポートして作成し、WPでメールアドレスが確認済みであることをマークする
- これらのユーザーがログインするとき（カスタムログインページ経由）、パスワードをリセットする必要がある
- ログイン時に、このセグメントのユーザーのみがパスワードを変更するように強制する方法（メールを入力したときにシステムが彼らがこのセグメントに属していることを認識する）
- または、ログインページに「[日付]以降にログインする場合は、パスワードをリセットする必要があります」というメッセージを表示する
- アクセスは機能するはずです！
新規登録ユーザーについては、メールアドレスを確認する方法を見つける必要があります。おそらく、パスワードをメールで送信することになるでしょう。
また、「メールアドレス確認済み」設定がWordPressプロファイルで選択されていなくても、ユーザーはDiscourseにSSOでログインできることに気づきました。ただし、Discourseに初めてアクセスする際には、どちらにしてもメールを確認する必要があります。それは良いことです。
これらの設定に副作用はありますか？
「いいね！」 1
はい、そのように意図されています。ほとんどのユーザーにとって、それは大きな障壁ではありません。注意すべき問題は、WordPressでメールアドレスが確認済みとしてマークされていない場合、DiscourseConnect経由で初めてDiscourseにログインするとき、Discourseはメールアドレスに基づいてWordPressユーザーとDiscourseユーザーを一致させないということです。インポートしたユーザーのメールアドレスを確認済みとしてマークする方法を見つけさえすれば、問題は発生しません。確認済みとしてマークしない場合、整理するのが大変になります。
有効にすると、Discourseでユーザーがユーザー名またはメールアドレスを変更できなくなります。
「いいね！」 1
ええ、たくさんテストしていて気づきました。インポートしたすべてのユーザーを認証済みとしてマークするカスタムスクリプトを作成します。
明確にしてくれてありがとう！
「いいね！」 1
常時 verbose /logs をオンにしておくことは問題ありませんか？
パフォーマンスに悪影響はありますか？
永続的にオンになっているケースを見たことがあります。パフォーマンスに大きな影響を与えるとは思いません。DiscourseConnect に関連しない問題のデバッグを試みている場合、ログが散らかるだけです。
「いいね！」 2
これまでのところすべて順調に動作しています！
一つ気づいた小さな点は、このフィールドに入力したパスが何であれ：
デフォルトのWordPressログインページになります。
例えば、以前は管理者としてログインするために使用していた/wp-adminに今アクセスしようとすると、/login/forumにリダイレクトされます。
理想的には、Discourseフォーラムからログインボタンをクリックした場合にのみ、ここにリダイレクトされるべきです。
これが通常の動作なのか、そしてこのように機能することが悪いことなのか疑問に思っています。
それは期待される動作です。「ログインページのパス」オプションは、デフォルトのWordPressログインパスをオーバーライドするために使用されます。これは、WordPressのlogin_urlフィルターにフックすることで実現されます。
デフォルトのログインルート/wp-login.phpは削除されないため、ブラウザのアドレスバーにURLを入力して直接アクセスすることもできます。/wp-adminに行く代わりに、/wp-login.phpにアクセスしてデフォルトのログインページを使用してください。
プラグインを更新して、Discourseへのログインのために「ログインページのパス」パスにのみリダイレクトするようにする方法は考えられますが、その変更には多少の作業が必要です。
「いいね！」 4
心配いりません。ちょっとしたことです。洞察をありがとうございます！
「いいね！」 1
Simon様、ログに以下のエラーが表示されているのですが、これは何を意味し、どのように対処すればよいでしょうか。ユーザーがログイン時にエラーが発生しているとの報告を受けて、これらのエラーに気づきました。
-
(google_oauth2) 認証失敗！csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRFが検出されました
-
認証失敗！request_error: OAuth::Unauthorized, 401 Unauthorized
-
(facebook) 認証失敗！no_authorization_code: OmniAuth::Strategies::Facebook::NoAuthorizationCodeError,
code（URL経由またはfbsr_XXX署名付きリクエストCookie経由）を渡す必要があります
これらのエラーは一般的ではないことに注意してください。ほとんどのログは正常に機能しているようです。
ユーザーからこのスクリーンショットを受け取りました。
彼は「メールがありません。サインアップリンクをクリックするとすぐに、次のページが表示されます…」と言いました。
ログイン/サインアップリンク（シークレットウィンドウで）をクリックすると、私には機能します。
参考までに、フォーラムのURLはこちらです。forum.projectvanlife.com
「Verbose SSO log」で始まるエントリは、ログインが成功していることを示していると仮定します。
「google_oauth2」、「OAuth::Unauthorized」、「facebook」のエラーについては、何が起こっているのかわかりません。以前は、DiscourseサイトでGoogleやFacebook経由でのログインを許可するように設定されていましたか？もしそうであれば、DiscourseConnectが有効になった現在、それらの方法でサイトにログインすることはできなくなります。Discourseの設定ページでGoogleとFacebookのログインを無効にすることを試してみてください。
ログインエラーを報告するユーザーについては、ユーザーのログイン試行に関連付けられた詳細なSSOログのエラーメッセージを探してみてください。そして、そのエラーがこのトピックで説明されている問題のいずれかに一致するかどうかを確認してください：https://meta.discourse.org/t/debug-and-fixing-common-discourseconnect-issues/103496。
ブラウザのアドレスバーに表示されているURLは https://projectvanlife.com/login/forum/javascript%3Avoid(0 です。
JavaScriptの一部が切り取られており、実際には javascript:void(0) にデコードされることを意図していると仮定します。それがどこから来ているのかはわかりません。おそらくユーザーのブラウザ拡張機能のいずれかからでしょう。ブラウザ拡張機能を無効にするか、シークレットウィンドウからログインを試すようにユーザーに依頼してみてください。
編集：@Sami_Syed、ログインページの「Sign Up」リンクをクリックすると、「javascript:void(0)」コードがパスに追加されます。そのリンクの href 要素は \"javascript%3Avoid(0)\" です。
おそらく、ログインフォームと同じパスでサインアップフォームを表示するために使用されているのだと思いますが、何かがうまくいっていないようです。DiscourseConnectを有効にする前に、これが正しく機能していましたか？
ログイン/サインアップフォームに使用されているプラグインに、サインアップフォームを別のページに表示するオプションがある場合、それを有効にすると、問題の簡単な解決策になるはずです。
今日はほとんどオフラインになりますが、もし行き詰まった場合は、後でこの問題の解決に協力できるかもしれません。
編集：この件について疑問に思っていたので、もう一度確認しました。「Register」タブは問題なく機能します。「Sign up」リンクには、上記で説明した問題があります。
したがって、この問題の簡単な解決策は、サインアップリンクを削除することです。
「いいね！」 2
その通りです。
はい、有効になっていました。しかし、そもそもどうやってFBやGoogle経由でログインをトリガーできるのでしょうか？現在のログインページにはその機能がありません。
あるいは、これは元々GやFBを使って登録したユーザーが、今ログインしようとしてうまくいかない場合に表示されるエラーなのでしょうか？
もしそうであれば、どうすれば解決できますか？
私が確認したところ、そこに正しいリンクを設定していなかったことが原因でした。よく気づきました、ありがとうございます！
何が原因でトリガーされているのか分かりません。ユーザーのブラウザが認証プロバイダーのURLをキャッシュしているのかもしれません。ただの推測ですが。
「いいね！」 1
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.