That was!! You save my day… Thanks a lot!
Could be wrong, but doesn’t this open up a x-site security vulnerability? See:
「いいね！」 2
I don’t know much in these matters, but here is my reasoning:
- “same site cookie” is enabled by default, so it is probably much better this way.
- “same site cookie” can be disabled, so it’s probably not a security hole by itself, rather a weakness that could be exploited in conjunction with others. Disable it at your own risks.
Anyone understands why disabling same site cookie enforcement prevents users from log in within an iframe?
iframe 内で Discourse を公式にサポートすることは可能でしょうか？
編集：おっと、2 年も経ってから投稿していたとは気づきませんでした。申し訳ありません。
これがサポートされる可能性は極めて低いです。
「いいね！」 2
Jeff さん、
まず第一に、Discourse は本当に素晴らしいツールです。開発してくださり、ありがとうございます！
第二に、iframe で埋め込んだ Discourse で想定される具体的な問題や、原理的に影響を与える制限事項について、どこかにドキュメント化されていますでしょうか？
よろしくお願いいたします！
こんにちは、Adam さん。しばらくぶりですね。ここで回答を試みます。
<iframe> を使用するとエラーが発生しやすく、Discourse の操作性が著しく低下し、原因究明が困難なバグが多発する可能性があります。また、Discourse の一部が「ウィンドウ化」され、長いトピックをスクロールするなどの機能が破綻しやすくなります。基本的に、iframe は Discourse の多くの機能をサンドボックス化してしまいます。
もし iframe の使用を検討されているのであれば、自社のサイトやアプリ、ポータルに合わせたヘッダー（ナビゲーションリンクを含む）をフォーラムに追加することを推奨します。ユーザーがフォーラムをクリックすると、同様のナビゲーションが表示されますが、これは別の URL でホストされていることになります。ヘッダー内のフォーラム以外のリンクをクリックすれば、再びサイトやアプリ、ポータルに戻ることができます。
これが何かのお役に立てれば幸いです。
「いいね！」 2
ご返信ありがとうございます！
具体的にどのような問題が予想されるのでしょうか？あるいは、iframe のコンテキストが重大な問題を引き起こす具体的な理由はありますか？
ここでいう「ウィンドウ化」とは具体的に何を指すのでしょうか？
これは当社のメインのディスカッションエリアでは採用する予定ですが、今回の特定のユースケースでは問題があります。当社はオンラインコースを運営しており、各コースは当社のサイト内の特別にテーマ化されたプライベートエリアで開催されます。コースコンテンツには教材、動画、スケジュール、ディスカッションエリアが含まれます。学生がコースを修了すると、コースの同級生との間で開始したディスカッションを継続できます。また、一般的なコース卒業生ディスカッショングループにも追加され、より大規模な公開ディスカッションフォーラムへの招待も受けられます。
当社のユースケースでは、ここで提案されたアプローチには以下の 2 つの問題があります：
- 当社のサイトのコースエリアのテーマ（ヘッダー、スタイル、サイドバーなど）は、Discourse 全体で使用する予定のテーマとは異なります。これに対応するためには、カテゴリごとに異なるスタイルやテーマコンテンツを使用できる必要がありますが、それは可能ではないようです。
- 当社の現在の（Discourse 以外の）実装におけるコースディスカッションには、スタイル、ヘッダー、サイドバーメニューが含まれています。これは学生がコースコンテンツに集中し、ディスカッション、教材、動画などをシームレスに切り替えられる、低ノイズの空間です。私の知る限り、Discourse をこの種の没入型環境を再現するように変更するのは困難です。もしそうでない場合は、その旨を教えていただければ幸いです！
ご協力をありがとうございます。
アダム
可能です。body 要素には現在のカテゴリを示すクラスが含まれており、これにより SCSS のネストされたセレクタを使ってテーマを簡単にスコープできます。
一般的には、コースエリアにいくつかの Discourse ウィジェットを追加することをお勧めします。例えば、別のサイトに Discourse トピックのリストを埋め込むというドキュメントで説明されている、サポートされている iframe トピックリスト機能などです。これにより、学生は現在のコースページに関連する最新のディスカッションのリストを確認でき、別のブラウザタブでそれに参加するためにワンクリックでアクセスできるようになります。
「いいね！」 3
こんにちは、Falco さん。
ご返信ありがとうございます。また、返信が遅れてしまい申し訳ございません。
残念ながら、当社のコース実装は、大幅な工夫をせずにカスタム CSS スコープで対応するにはやや複雑です。例えば、ヘッダーメニューには現在ログインしているユーザーが登録しているコースのドロップダウンが含まれています。これは WP データベースからログインユーザーに基づいて動的に生成されるため、Discourse 上で同様に再現するのは困難です。
コースエリアのサイドバーメニューには、特定のコースに固有のさまざまな種類のコースコンテンツへのリンクが含まれています。私の理解が正しければ、ご提案の仕組みを機能させるには、すべてのコースのすべてのコンテンツをテーマにハードコードし、CSS で body クラスに応じて表示または非表示にする必要があるとのことですが、合っていますでしょうか。
代替案として、Discourse 側でクライアントサイドの JavaScript を使用し、API からコンテンツを取得して表示する方法が考えられます。他サーバーに対して XmlHttpRequest を行うカスタムスクリプトを追加することは可能でしょうか。このアプローチが不可能になるような理由は考えられますか？
この質問への回答をまだ楽しみに待っています。
よろしくお願いいたします！
はい、可能です。ただし、そのリクエストがページのレンダリングをブロックしないように注意してください。
「いいね！」 2