WordPress ウェブサイトで Discourse フォーラムを接続して約 20 万人のユーザーが利用しています。
OAuth Single Sign On - SSO (OAuth client) および WP-Discourse プラグインを使用して、WP の投稿を Discourse に接続し、ユーザーは WP で WP ユーザーインスタンスでログインすると、Discourse にもログインします。
ここで問題が発生しました。Discourse の設定でログインを必須としないに設定すると、問題が発生します。
手順は以下の通りです。
- ユーザーが WordPress にログインします。
- ユーザーが Discourse にリンクされているリンク (トピック、Discourse へのリンクなど) をクリックします。
==> ユーザーはログインしていないかのように Discourse を表示します。しかし、WordPress にログインした瞬間にログインしています。
- ユーザーが Discourse のログインボタンまたはトピックリンクをクリックします。
- ページがリフレッシュされ、ユーザーは認証されます。
これは想定内の動作であり、以下の対応が必要であると聞きました。
- ユーザーがログインしている場合、WordPress から Discourse へのすべてのリンクは次のようである必要があります:
https://our-discourse-instance.com/session/sso?return_path={Discourse の元の URL、トピック URL など}
- ユーザーがログアウトしている場合、Discourse の元の URL (
https://our-discourse-instance.com/t/topic-slug のように) に直接リンクできます。
これは問題を解決するための間違ったアプローチであると強く疑っています。なぜなら:
- Discourse にログインしているユーザーがトピック URL をコピーして、WP/Discourse にログインしている他のユーザーと共有した場合はどうなりますか？上記 #2 のようなエラーが発生します。なぜなら、そのような URL サフィックスは追加されないからです。
- ログインしているユーザーは、なぜ
session/sso?return_path= にリダイレクトされる必要があるのですか？これにはどのような技術的な理由とロジックがありますか？
- ユーザーがページをリロードするとすぐに (トピック URL を読み込む、ログインを押すなど)、なぜ解決されるのですか？
- これは実際の想定されるアプローチである場合、なぜもっと広く文書化されていないのですか？
- Discourse から任意のトピック URL を取得できる API で、なぜこれが言及されていないのですか？ログインしているユーザーはコンテンツにすぐにアクセスできず、奇妙なリロードを行う必要がある、または実際には何も変換しない奇妙な URL パラメータを追加する必要があるとはどこにも書かれていません。
これは想定される動作ではないと確信しているので、権威ある意見をいただけると幸いです。
もしそうであれば、以下について質問したいと思います。
- なぜこれが実際に必要なのか、そして
- どの程度対応が計画されているのか (これは明らかに理想的ではありません。私の理由のポイント 1 を参照してください)。
ありがとうございます。
angus
(Angus McLeod)
2
こんにちは @smileBeda さん、
ドキュメントはこちらで確認できます。
フォーラムのどのパスにアクセスしてもユーザーが自動的にログインにリダイレクトされるようにしたい場合は、login required 設定を有効にする必要があります。これは確かに期待される動作です。
「いいね！」 1
確認してくれた @angus さん、ありがとうございます。
まだ少し奇妙に感じますが、ユーザーが WordPress でログインした際に session/sso?return_path= へのリダイレクトを追加しました。
リターンパスは、WordPress からのリファラー（もしあれば）または WordPress のホームページに設定しました。
これにより、両方のインスタンスでユーザーがログインしていることが保証され、うまく機能します。
ただし、デフォルトでは Discourse は「外部」リターンパスを許可しないため、Discourse の設定で「任意のリターンパス」を許可するように有効にする必要がありました。
この設定を有効にすることに問題はないでしょうか？
親切な返信と「公式な」確認、そしてドキュメントへのリンクをありがとうございました！
angus
(Angus McLeod)
4
通常、クライアントにはこのような自動リダイレクトを避けるようにアドバイスしています。この問題だと感じる理由は理解できますし、珍しい感情ではありません。しかし、標準的なアプローチは、あなたのサイトと同じくらい、あるいはそれ以上の規模の多くのサイトで問題なく機能します。自動リダイレクトは一部のシナリオでは機能せず、UXを低下させる可能性があります。
あなたが期待している「一度ログインすればどこでも自動的にログインされる」というのは、Metaのような相互接続されたサービス（例：FacebookにログインするとInstagramにもログインできる）が、中央集権的に管理されたプラットフォームであるために機能することがあります（ただし、中央集権的なサービスでさえ、DiscourseConnectと同じように機能する場合もあります）。
対照的に、ここでは独立したオープンソースソフトウェアフレームワーク（WordPressやDiscourse）を扱っています。あなたが期待するような方法で効果的に機能するように設定することは可能ですが、特定のユースケースを考慮したカスタム作業が必要です。これは、数千もの異なるユースケースに対応するDiscourseConnectのような認証システムが機能する方法には決してなりません。
いいえ、ただし、その必要性の前提については疑問を呈するでしょう。しかし、それ以上の情報がなければ、それを使用することに問題はないと思います。
「いいね！」 1
これは、ここで説明されているような無効なリダイレクトのリスクの可能性がありますか？
「任意の戻り値を許可する」ことで、どこにでもリダイレクトできることは理解できます。
しかし、リダイレクトURLで機密データが共有されていないため、これが実際のリスクになるかどうかはわかりません。
ありがとうございます！
@Angus - 上記の最後の疑問について、何かご存知でしたら教えていただけますでしょうか？
ありがとうございます！
angus
(Angus McLeod)
7
申し訳ありませんが、それは私が見ることができない、またはあなたとの明確な関係がないあなたのセットアップの機密部分に関するアドバイスを提供することになります。
特にフォーラムの規模と適用される関連規制を考慮すると、その質問については具体的で情報に基づいたアドバイスを得ることをお勧めします。
明確ではなかったかもしれませんが、以下に説明します。
- Discourse フォーラムでは、Discourse の設定で「任意の返信パス」を許可する設定を有効にします。
- これは、
your-discourse.tld/session/sso?return_path=ANYTHING のような URL でアクセスできるようになることを意味します。
- この ANYTHING は外部 URL になる可能性があります。
これにより、少なくともフィッシング詐欺の試みにつながる可能性のあるセキュリティ脆弱性が生じます。
- 悪意のあるウェブサイトは、「素晴らしいコミュニティにアクセス！」というボタンを作成します。
- ボタンのリンクは
your-discourse.tld/session/sso?return_path=BACK TO MALICIOUS SITE になります。
- ユーザーがボタンをクリックし、コミュニティでログインすると、悪意のあるサイトにリダイレクトされます。
- そこで、悪意のあるアクターは、コミュニティとまったく同じように見えるページを実装し、「ログイン中に問題が発生しました。もう一度お試しください」と表示します。
- ユーザーは、コミュニティの外観に一致する、見栄えの良いログインフォームを送信します。
これにより、悪意のあるアクターはログインデータを取得できるのでしょうか？
したがって、「任意の返信パス」の設定は、ユーザーがログインするサイトでは、各ユーザーが正確に何に注意すべきかを知らない限り、絶対に使用すべきではないでしょう。
あなたもそのリスクを認識しますか？
Discourse の開発者は、この設定とやり取りできるプラグイン/コードを作成する際に、「はい、問題ありません」または「いいえ、絶対にダメです」という明確な回答を提供できないのでしょうか？
URL パラメータで変更できることはそれほど多くありません。存在するかしないか、外部を許可するかしないかのどちらかです。
もしかしたら、私が触れるべきではない領域に踏み込んでいるのかもしれません。「セキュリティ問題についてはここで議論しないでください」ということでしょうか？もちろん理解できます。多くのプラットフォームでは、有効化する際に明確に定義されていない潜在的なセキュリティ問題について公に話すことを許可していません 
angus
(Angus McLeod)
9
質問に自分で答えていると思います。
設定の有効性は、その使用方法に依存するためです。まさにそれが、設定なのであって単なる「機能」ではない理由です。もしあなたの質問に簡単な答えがあったなら、そもそも設定は存在しなかったでしょう。
このやや弁護士的な回答がもどかしいことは承知しています。しかし、ここではお答えできない、あなたのユースケースに特化したアドバイスが必要です。