Discourse Connect を WP をメインの登録およびログインインスタンスとしてセットアップしました。
異なるフローを持つ 2 つのユーザー登録フォームがあります。
- ホームページからの標準登録 (これは古いもので、Discourse にもユーザーを作成します)
- ツールフローを使用したユーザー登録。(これは WP ユーザーを作成しますが、Discourse にはユーザーを作成しません)。
Discourse プラグインに、登録フォーム固有の設定は見当たりません。ユーザーに移動しても、2 番目のフォームの WP に Discourse ユーザー名は表示されません。リンク
2 つの質問があります。
- ここで何を見落としている可能性がありますか? 新しいフォームで機能させるために、追加の設定が必要ですか?
- WP に存在するメンバーのために、Discourse でユーザーを作成し、WordPress に接続するにはどうすればよいですか?
修正: さらに分析したところ、最初のフォームからでも一部のユーザーが Discourse に作成されていないようです。
「いいね!」 1
この問題に直面した人はいますか?本当に困っています。
angus
(Angus McLeod)
3
@Himanshu_Singh様
ユーザーがどのように表示するか、段階的に説明していただけますでしょうか。
- 「標準登録」フォームでは何が起こりますか?
- 「ユーザー登録」フォームでは何が起こりますか?
例:
- ユーザーがフォームにアクセスし、詳細を入力します。
- ユーザーはディスコースにリダイレクトされます。
意図しないことが発生した場合のステップと、代わりに発生させたいステップを含めてください。
「いいね!」 2
Angus様
標準登録の場合、
- ユーザーはフォームにアクセスし、名前、メールアドレス、パスワードを追加します。
- 次に、ユーザーは自動的にログインされます。
- その後、ユーザーがコミュニティリンクをクリックすると、Discourse ConnectプラグインがDiscourseで新しいユーザーを作成したため、自動的にログインされます。
2番目のフォームの場合、
- ユーザーは名前とメールアドレスを追加します。
- 一時パスワードを提供します。
- 残りのプロセスは同じです。つまり、ユーザーはサインアップ時に自動的にログインされます。
- ただし、この場合、ユーザーはDiscourseに作成されません。
登録フォームの変更によってトリガーされるDiscourse Connectの設定は見当たりません。2番目のフォームの場合にトリガーされないWPでのユーザー登録時にトリガーする必要があるフックはありますか?
実際、Discourseでユーザーを作成するために使用されるWordPressのフックは何ですか?DiscourseでアクティビティをトリガーするためにAPI呼び出しが行われているはずです。何らかの理由でそれが実行されなかったのでしょうか?
「いいね!」 1
angus
(Angus McLeod)
5
これらのユーザーがDiscourseで「ログイン」をクリックするとどうなりますか?彼らがそれを試みたときに正確に何が起こるかを説明してください。WordPressで作成された後にユーザーが管理パネルに表示されないことは理解していますが、これは少し異なる質問です。
「いいね!」 1
WPに登録済みのユーザーの最初のケース
ユーザーはDiscourseでログインをクリックする必要がなく、WPの以下のリンクをクリックすることで自動的にログインされます。
https://community.showprowess.com/session/sso?return_path=/
WPからDiscourseにリンク https://community.showprowess.com/ のみを使用してアクセスした場合、ユーザーはログインされておらず、Discourseのログインボタンをクリックしてユーザーをログインさせる必要があります。
ユーザーがログインすると、WPからログアウトするまでログイン状態が維持されます。
これは問題を引き起こします。なぜなら、ユーザーが /session/sso?return_path=/ をクリックしないと、ユーザーはログインされないからです。これにより、WPからDiscourseへのプライベートメッセージページへのユーザーのリダイレクトが制限されます(これは製品の一部として必要な機能です)。
たとえば、ユーザーXにプライベートメッセージを送信したいとします。
WPのカスタム投稿にこのリンクを追加します。
https://community.showprowess.com/new-message?username=x&title=Message%20from%20
これが最初にクリックするリンクであるため、メッセージボックスは開きません。代わりにDiscourseにログインされます。次に、戻って同じリンク(メッセージリンク)を再度クリックして、機能させる必要があります。
これは次のようになります。
これはユーザーにとって迷惑です。
以前は、ユーザーはDiscourseに自動的にログインされ、URL https://community.showprowess.com はログインされたDiscourseページに移動したため、これらすべてが正常に機能していました。おそらく、ユーザーはブラウザのCookieなどを使用してログインしていましたが、それはもう機能しません。
Discourseに登録されていないユーザーの場合
これは両方のフォーム、つまり新しいフォームと古いフォームで発生しています。
この場合、再度ログインしてオンボーディングプロセスを進めました。今回はユーザーがDiscourseに作成されました。それ以前は、ユーザーはDiscourseに存在しませんでした(再度ログインする前に管理エリアの新規ユーザーリストを確認しました)。
上記と同じ手順に従いました。/sessions URLをクリックしてDiscourseに自動ログインします。ドメインコミュニティのみをクリックしてもログインされません。
残念ながら、ユーザーが登録時に作成されず、最初のログイン時に作成されるケースを再現できません。これはすべての新規ユーザー登録で発生するわけではなく、非常に奇妙です。
お役に立てば幸いです。
「いいね!」 1
angus
(Angus McLeod)
7
正直なところ、この問題の説明が、以前のWordPressの登録フォームが2つあるという問題の説明とどのように関連しているのか、少し混乱しています。しかし、それでもお手伝いできると思います。
まず理解しておいていただきたいのは、2つの異なるドメインにある2つの異なるサービスに瞬時にログインする方法は(そして、これまでもありませんでした)、存在しないということです。サービスAのドメインAでログインしているように見え、ドメインBのサービスBにアクセスしたときにログインしている場合、実際には、ドメインBにアクセスしてログインプロセスが開始されたときに、サービスA経由でサービスBにログインしただけであり、それ以前ではありません。
また、セッションを必要とするアプリの特定の場所にユーザーをリダイレクトしたいという、あなたが説明している特定のシナリオを除けば、ほとんどのユーザーは、サービスBで「ログイン」をクリックする必要があるという事実を気にしないか、それに気づかないということも理解しておく必要があります。アイデンティティソリューションでクライアントと協力してきた経験から、サイト管理者はユーザーよりもこの点に敏感であることが一般的です。
この仕組みは変わっていません。ユーザーが「自動的に」ログインしているように見えるときは、実際にはWordPressにリダイレクトされ、WordPressでのセッションが認証されるとDiscourseにリダイレクトされています。WordPressにすでにログインしている場合、このリダイレクトはユーザーが何もする必要なしに発生するため、「自動的に」Discourseにログインしたように見えます。
「自動」ログインをトリガーし、ログイン後にDiscourseの特定の場所にリダイレクトする1つの方法は、すでに共有したパスを使用することです。
https://community.showprowess.com/session/sso?return_path=[any path in Discourse]
ユーザーがこのURLを使用するときにWordPressにログインしているが、まだDiscourseにログインしていない場合、次のようになります。
- Discourseは自動的にDiscourseConnectログインプロセスを開始します。
- ユーザーのブラウザはWordPressにリダイレクトされます。
- ユーザーはすでにログインしているため、自動的にDiscourseにリダイレクトされます。
- 1でURLに使用された
return_pathの値がある場合、ユーザーはその場所にリダイレクトされます。
ユーザーの視点からは、ブラウザが一瞬読み込まれるのが見えるだけで、実質的にはDiscourseに「自動的に」ログインし、アプリの特定の部分にリダイレクトされます。
サイト設定 discourse connect allows all return paths を true に設定すると、return_path を任意のURL、別のドメインにすることもできることに注意してください。
「いいね!」 2
ありがとうございます。これは、WPからDiscourseへのユーザーの自動ログインの問題を解決するのに役立ちます。return_pathを使用して、ユーザーをDiscourseの任意のページにリダイレクトできます。これにより、ユーザーをメッセージページにリダイレクトする問題が解決します。
しかし、ユーザーがWordPressで作成されたときにDiscourseでユーザーが作成されない場合がある理由がまだわかりません。SSOからDiscourseでユーザーが実際に作成されるのはいつかご存知ですか?
- WordPressでユーザーが作成されたときですか?
- 新しいWordPressユーザーがDiscourseにアクセスしようとしたときに、ユーザーが作成され、ログインされ、Discourseにリダイレクトされるのですか?
WordPressでユーザーを作成するために、どのフックを使用してDiscourseでユーザーを作成しますか?
WordPressでユーザーが作成されたときにDiscourseでユーザーが作成されないエッジケースがどのようなものか理解しようとしています。
実践的なユースケース:
毎週、新しいユーザーにメッセージで挨拶しています。先週、30人のユーザーがWPに参加し、16人がDiscourseで作成されました。ウェルカムメッセージでタグ付けしようとすると、全員をタグ付けできません。これは私にとって非常に奇妙です。
Angus、助けてくれてありがとう。感謝しています。
「いいね!」 1
angus
(Angus McLeod)
9
デフォルト設定では、ユーザーはDiscourseConnectを使用してDiscourseに初めてログインしたときにDiscourseで作成されます。それまでの間、Discourseにユーザーは存在しません。
WP Discourseプラグインには、「ログイン時にDiscourseユーザーを作成または同期する」という設定もあります。これが有効になっている場合、ユーザーがWordPressに登録した後、Discourse APIを介してユーザーが作成されます。この設定はwp_loginアクションを使用するため、この機能が動作するには、ユーザー登録プロセスでそのアクションをトリガーする必要があります。
「いいね!」 2
これで全てが理解できました。ありがとうございます、Angusさん。
「ログイン時にDiscourseユーザーを作成または同期する」設定をオンにしています。一部のユーザーはWPで登録しても、初回ログイン時にコミュニティにアクセスしないため、Discourseでユーザーが作成されていません。後でログインしてコミュニティURLをクリックすると、ユーザーが作成される可能性があります。
現在のWPでの登録後の自動ログインは、WP_loginを使用していません。
add_action( 'cred_save_data', 'cred_autologin_V3', 10, 3 );
function cred_autologin( $post_id, $form_data ){
if ( ID1 == $form_data['id'] ) { // 必要に応じて編集
wp_set_current_user( $post_id );
wp_set_auth_cookie( $post_id );
// wp_redirect( home_url( '/some-ending-page/' ) );
// exit();
}
}
WP登録時にDiscourseユーザーを作成したいと考えています。
APIを実行できるカスタムフックをユーザー登録フォームに持っています。API経由でDiscourseユーザーを作成するために、カスタムフックに追加できるコードはありますか?
これが、カスタムフックからwp_loginをトリガーする方法がわからない部分です。
「いいね!」 2
指示通りに実行したのですが、以下のエラーが発生します。
add_action( 'cred_save_data', 'cred_autologin_V3', 10, 3 );
function cred_autologin( $post_id, $form_data ){
if ( ID1 == $form_data['id'] ) { // 必要に応じて編集
wp_set_current_user( $post_id );
wp_set_auth_cookie( $post_id );
do_action( 'wp_login' );
// wp_redirect( home_url( '/some-ending-page/' ) );
// exit();
}
}
メッセージ: Uncaught ArgumentCountError: Too few arguments to function WPDiscourse\WordPressEmailVerification\WordPressEmailVerification::verify_email_after_login(), 1 passed in /home/customer/www/[domain.com/public_html/wp-includes/class-wp-hook.php on line 307 and exactly 2 expected in /home/customer/www/[domain.com/public_html/wp-content/plugins/wp-discourse/lib/wordpress-email-verification.php:128
メール認証をバイパスする別のコードがあります。
add_filter( 'discourse_email_verification', 'disable_discourse_email_verification_prowess');
function disable_discourse_email_verification_prowess() {
wp_mail( 'himanshu@eshowprowess.com', 'User verified', 'Status must change' );
return false;
}
これはコードの順序の問題でしょうか、それとも wp_login アクションに何らかのパラメータを渡す必要がありますか?
編集:ユーザーはWPで作成され、ログインしましたが、Discourseではユーザーが作成されていませんでした。
「いいね!」 1
angus
(Angus McLeod)
13
アクションについていくつか調べてみることをお勧めします。WPのドキュメントは私よりも良いリソースです。残念ながら、ここにカスタムWPログインコードを統合する最善の方法を見つけることはできません。あなたが抱えている問題については、原因を突き止めたと思います。
「いいね!」 3
system
(system)
クローズされました:
14
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.