Discourse IDの仕組み

[Moin]

ドメイン名を変更した後の対処法に関する情報を最初の投稿に追加できるかもしれません。

@pmusaraj

Railsコンソールにアクセスできる場合は、discourse id設定のクライアントIDとシークレットを空にしてから、Enable Discourse ID設定をオフ/オンに切り替えると、新しい登録がトリガーされます。

@在云端_裸奔

./launcher enter app
rails c
SiteSetting.discourse_id_client_id = ""
SiteSetting.discourse_id_client_secret = ""

[mcwumbly (Dave McClure)]

最初の投稿に以下を追加しました。

@rishabh

ドメイン名を変更した後のIDの再設定

サイトのドメイン名を変更した後、新しい登録をトリガーするには、次の手順を実行する必要があります。

1. Discourse ID の設定のクライアントIDとシークレットを空にする
2. Discourse IDを有効にする設定をオフ/オンに切り替える。

Railsコンソールにアクセスできる場合：

./launcher enter app
rails c
SiteSetting.discourse_id_client_id = ""
SiteSetting.discourse_id_client_secret = ""

[Moin]

レールスクリプトをステップ1のすぐ下に置いた方がいいと思います

@rishabh

1. discourse ID設定のクライアントIDとシークレットを空にする

これらは非公開のサイト設定なので、レールコンソールを使用する以外に変更する方法はありません

config/site_settings.yml

[0cjs (Curt J. Sampson)]

Discourse ID アイデンティティプロバイダーを作成する高レベルの目標について、誰か教えてくれませんか？ これ自体に悪い点はないように思えますが、見落としている良い点があるかどうか確認したいのです。

私には、GitHub、Google、Apple、または Facebook を使用している人々にとって、Discourse ID を作成する利点はないように思えます。いずれにせよ、Discourse サイトへの登録やログインは「ワンクリック」（まあ、ほんの数クリックですが）で完了するからです。では、なぜこのオプションが提供されているのでしょうか？ 単なる一貫性のためでしょうか？

GitHub/Google などのアカウントと分離してアカウントを保持するという点では、Discourse ID は理にかなっているように思えます。メールアドレスとパスワードで認証する場合、何らかの二段階認証（2FA）を提供していると推測します。

最後に、Discourse ID は他の非 Discourse システムでも使用できるのでしょうか？ 技術的には、それを望むほぼすべてのシステムに対して ID プロバイダーとして機能しそうですが、これは推奨されていますか？ それとも推奨されていませんか？ また、将来的に Discourse ID が壊れてしまう可能性のある機能でしょうか？

私は、デジタル主権の観点から、そして単に「Google/MS などの依存から脱却したい」という観点から、誰がアイデンティティを提供し、なぜ提供しているのかに興味があります。したがって、代替のアイデンティティプロバイダーの動向を理解することは、私にとって非常に興味深いことです。

[pmusaraj (Penar Musaraj)]

いくつかの上位目標はありますが、一般的に言って、2つの主な利点に集約されます。管理者にとっては、GitHub、Google、Apple、Facebookのログイン設定と維持が不要になります。それぞれを個別に設定・維持するのはそれほど難しくはありませんが、複数の手順と維持管理が必要となります。また、Appleの場合にはコストもかかります。

エンドユーザーにとっては、現時点では大きな違いはありません。長期的には、十分な数のコミュニティがDiscourse IDを採用すれば、IDを通じてコミュニティ（ユーザーが参加するコミュニティ）の通知制御、ユーザーアカウントのカスタマイズなどのより良い集中型インターフェースを提供し、新しいコミュニティの発見も改善できることを願っています。