これに関する投稿をいくつか見かけましたが、ほとんどが、この機能は閉鎖的なコミュニティでのみ利用可能であると述べています。Auto-sign-in with the OpenId Connect Plugin and AWS Cognito - support - Discourse Meta
How to auto-login user in application web view - dev / sso - Discourse Meta
私たちは、製品登録プロセスの一部としてのみアカウントを取得するコミュニティを望んでいますが、フォーラムのコンテンツは、人々がGoogle経由でセルフヘルプを試みている場合に、認証されていない状態でも適切な結果を得られるように公開したいと考えています。（また、コンテンツのSEOターゲットにヒットできる可能性もあります）
これは可能でしょうか、それとも夢物語でしょうか？この質問をしたのは私が初めてではないようですし、この製品機能を望んでいるのも私だけではないようです。
編集：特に、OIDC仕様のこの特定の側面について話しています - Auto-sign-in with the OpenId Connect Plugin and AWS Cognito - #8 by david
pfaffman
(Jay Pfaffman)
2
Cognitoにログインしている一部のユーザーが、返信しようとしたときにログインダイアログが表示されるのを避けたい、ということでしょうか？ Discourse Connectではそれがデフォルトの動作だと思っていました。
サイトを匿名ユーザーとGoogleに公開することができます。
「いいね！」 2
理想的には、Discourseを閲覧しているユーザーは、アカウントを持っている場合は常にログインしている状態であるべきです。そうすれば、すべての閲覧データをキャプチャできます。製品ユーザーが製品内のリンクをクリックしてコミュニティを表示した場合に認証されるようにします。また、他の場所で認証されている場合にのみ表示されるべきリンク（たとえば、アカウントページ）も同様です。
ただし、ユーザーがGoogle経由でセルフヘルプを試みてコミュニティにたどり着いた場合、システム内の他の場所で認証されていても、コミュニティと直接やり取りしようとするまでそのデータをキャプチャすることはできません。この問題を解決するには、login_requiredサイト設定を有効にするしかないようです。これは、私の理解が正しければ、実質的にサイトをプライベートにするものです。
ありがとうございます。知りませんでした。私は3つの別々の製品のすべてを理解しようとしているCMであり、それぞれの詳細を把握しようとして頭が爆発しそうです！すべてを整理しようとする投稿がさらにいくつかあると思いますが、辛抱強く対応していただき感謝します。
「いいね！」 2
simonk
(Simon King)
4
一般的なケースでは、それは不可能になります（匿名のユーザーがログインするように促さずにアカウントを持っているかどうかをどのように判断できますか？）。ただし、ユーザーが SSO サイトでアクティブなセッションを持っているかどうかを検出することは可能です。
そのトピックはかなり古いですが、原則は依然として適用されると思います。基本的に、適切な CORS サポートを備えた URL を追加し、ユーザーがアクティブなセッションを持っているかどうかを示す JSON 応答を返します。次に、その URL をクエリし、アクティブなセッションが存在する場合は SSO プロセスをトリガーする Discourse テーマにいくつかの JS を追加します。
「いいね！」 2
david
(David Taylor)
5
残念ながら、一般的な答えは前回とほとんど同じです。
私が話していた仕様はOpenID Connect Session Managementです。残念ながら、このiframeベースのソリューションは、多くのブラウザがデフォルトでサードパーティCookieをブロックするようになったため、ますます有用性が低下しています。IDプロバイダーとDiscourseが同じ「オリジン」にある場合にのみ、確実に機能するようになりました。
@simonk が言ったように、IDプロバイダーによっては、テーマコンポーネントを介してカスタム実装が可能かもしれませんが、Discourse自体に追加できる一般的なソリューションは認識していません。
「いいね！」 3
david
(David Taylor)
7
「返信」をクリックするとログインフローがトリガーされるというのは全くその通りです。また、DiscourseConnect（または他のシングルログインプロバイダー）が使用されている場合、Discourseのログインモーダルはスキップされます 
しかし、OPは、ユーザーが返信や「ログイン」をクリックする必要なく、自動的にログインされるようにしたいのだと思います。そのような設定であれば、ユーザーはメインサイトとコミュニティ間をシームレスに移動できます。私たちは数社のお客様のためにこれを実現しましたが、これらは簡単に一般化できないカスタム実装でした。
アプローチの1つを例として挙げます。フォーラムがforum.example.comにあり、メインサイトがexample.comにある場合、フォーラムはexample.comからのCookieを読み取ることができます。そのため、テーマコンポーネントはCookieの存在を確認し、次のようなことを行うことができます。
const cookie = require("discourse/lib/cookie").default;
if(cookie('name_of_example_com_auth_cookie') && !api.getCurrentUser()){
// ユーザーはexample.comの認証Cookieを持っています。ほぼ確実に
// そこでログインしているので、認証フローを実行しましょう
window.location = "https://forum.example.com/auth/oidc"
}
（ここではさまざまな条件が適用されます。例：Cookieはhttp_onlyであってはならず、host-only Cookieであってはなりませんなど）
「いいね！」 5
まさにその通りです。それが可能であることは良いことですが、カスタムです。
また、ユーザーが返信をクリックすると、実装によってはログインダイアログがスキップされることを知らなかったため、当初の懸念の多くが軽減されます。それが私が避けたい主な参入障壁であり、実装できることを嬉しく思います。
もちろん、私のようなデータオタクは理想的なバージョンを望んでおり、それに近づくことを目指すかもしれません。現時点で可能であることを知っておくだけで十分です。皆様、改めてお時間をいただきありがとうございました。
「いいね！」 2
system
(system)
クローズされました:
9
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.