custom auth systemへの統合：メールアドレスがユニークでない場合？

SSO
1

既存のシステムにDiscourseを統合し、サポートのためのDiscordサーバーへの依存をなくしたいと考えています。すでに独自の認証システムがセットアップされており、摩擦を減らすために可能であれば再利用したいと考えています。しかし、当社の場合はメールアドレスは一意である必要はなく、ユーザー名のみが一意であればよいのです。Discourseはメールアドレスがグローバルに一意であるという前提に依存しているようで、直接統合することができません。

有望そうに見えたDiscorseConnectを確認しましたが、次のように記載されていました。

Discourseはメールアドレスを使用して、外部ユーザーをDiscourseユーザーにマッピングします。

これは、複数のアカウントが同じメールアドレスを使用できる（そして実際にも使用している）ため、当社のケースでは機能しません。

次にDiscourse OAuth2 Basicを調べましたが、一見するとメールアドレスを必要としませんでした。

唯一必須の属性はidです。

しかし、後で、OAuthソースから提供されない場合は、手動でメールアドレスを入力する必要があると述べられています。

SoundCloudはメールアドレスを提供しないため、ユーザーはDiscourseで初めてサインアップする際にメールアドレスを提供し、確認する必要があります。

このような場合でも、Discourseを使用することは可能でしょうか？ユーザーがDiscourseに初めてログインする際に、手動でメールアドレスを提供するだけであれば問題ありません。しかし、メールアドレスを実際のログインプロセス中に使用できないように設定できる場合に限ります（ユーザー名とパスワードのみを使用するように強制する）。メールアドレスをログインフォームから完全に無効にできれば、当社側での摩擦が減ります。なぜなら、当社ではメールアドレスでのログインをサポートしておらず、ユーザーにも試してほしくないからです。

「いいね！」 3
2

ほとんど方法がありません。メールアドレスは一意でなければなりません。

次のようなハックを試すことができます。
myaddress@gmail.com → myaddrerss+username@gmail.com

これは、ほとんどの場所でサポートされているはずの+アドレスをサポートする場所で機能します。

3

これを検討しましたが、oauthフローにどのように影響するか、またはサインアップ/サインインの摩擦が増えるかどうかはわかりませんでした。この種の変更はユーザーには見えないため、この変更されたメールアドレスを入力しないとログインに失敗します。また、現在の В учетной записи серверもこれらの変更を認識していないため、変更されたメールを入力しても、レコードで見つけることができないのではないでしょうか？

また、これはすでにメールエイリアスを使用しているユーザーを壊すことにもなりませんか？

4

良い解決策はありません。

ユーザー名でログインした場合を除きます。

メールログインを許可した場合（DiscourseConnectではできないと思いますが）、メールリンクが送信されていれば機能したはずです。

それを認識させる必要があります。それが第一歩だと思います。

別の醜い選択肢は、あなたのシステム上のユーザーに、Discourseにログインできるのは（それがどのように定義されるにせよ）「最初の」ユーザーのみを許可することです。

別の醜い解決策は、あなたのシステム上のユーザーに、アカウントごとに一意のアドレスを取得することを強制することです。

5

…メールサーバーがプラスアドレス指定をサポートしている場合に限ります。これは保証されていません。

「いいね！」 1
6

はい、もちろんそうです。それが私が目指していることです。メールでのログインを一切許可せず、ユーザー名ログインのみを唯一の方法とするソリューションを探していました。Oauthサーバーから完全に偽のメールを送信することで、メールサポートを実質的に完全に無効にしても構いません（たとえば、メール通知なし）。しかし、ログインにメールを使用できる機能がまだ利用可能な場合、ユーザーはそれを試みて失敗するため、これは摩擦を生み出します。

これは実質的に、ユーザーごとに2つの別々のメールを追跡することを私たちに強制することになります。これは望ましくありませんし、@supermathieが言及したように、すべてのプロバイダーで確実に機能するわけではなく、ユーザーに覚えておく必要があるこのフォーラム固有のメールアドレスについて伝えなければならないため、依然として摩擦が生じます。

はい、技術的には機能します。しかし、明白な理由から、他のすべての人々がフォーラムに参加できなくなるため、実際的な解決策として使用することはできません。

これは技術的な理由から私たちが行うことができないことです。最も明白なのは、すでに他のアカウントと同じメールアドレスを持つユーザーがいることです。しかし、より大きな問題は、私たちがこれを単純に行えないことです。Discourseを組み込みたいと考えているプロジェクトは、任天堂ネットワークのサーバーエミュレーションプロジェクトであるPretendo Networkです。任天堂はアカウントシステムでメールアドレスを再利用することを許可しており、サーバーを正確にエミュレートするためには、私たちもそうしなければなりません。ユニークなメールを強制することは、私たちのカードにはありません。

私のチームの誰かが、Discourseから送信されたメールをユーザーの実際のメールにマッピングし、そのように転送する独自のSMTPサーバーを実行することを提案しました。これは機能しますが、明らかに私たちにとって技術的なコストが高くなり、メールログインを無効にするという問題と、私たちのケースで生じる前述の摩擦を依然として解決しません。

Discourseをフォークするか、他のフォーラムソリューションを使用して必要なことを行う必要があるようです。

7

記憶を頼りに話しますが、ダミーですが一意のメールアドレスで DiscourseConnect を使用できます。ユーザー名が一意であることが保証されている場合、実装は非常に簡単になる可能性があります。メールアドレスは username@invalid.com のようなものに設定できます。

ユーザーは現在使用している方法でシステムにログインします。その後、システムはダミーのメールアドレスで SSO ペイロードを生成します。

このアプローチの欠点は、Discourse でメールを無効にする必要があることです。これは、disable emails 設定を yes または non-staff に設定することで実行できます (スタッフ メンバーが一意のメールアドレスを持っている場合)。

重複したメールアドレスを持つユーザーのために、プラス記号 (+) を使用したメールアドレスを検討することもできます。最後に確認したとき、Discourse はプラス記号 (+) を使用したメールアドレスを一意と見なしていました。DiscourseConnect ペイロードで使用する前に、メールアドレスを URL エンコードしてください。このリスクは、ユーザーが重複したメールアドレスを持ち、プラス記号 (+) を使用したメールアドレスをサポートしないメールサーバーを使用している場合、Discourse からのメールを受信できませんが、他のユーザーは Discourse のメールを受信できるということです。

はい、ただし特定のケースのみです。ユーザーが DiscourseConnect を実装する前に Discourse アカウントを作成した場合、Discourse は既存のユーザーを DiscourseConnect ペイロード内のメールアドレスに関連付けようとします。新しい Discourse サイトを開始する場合、これは問題になりません。

メールマッピングの問題が発生したもう 1 つのケースは、認証プロバイダーサイトのコードに欠陥があったために、Discourse サイトの SSO レコードが破損した場合です。その場合、サイトは Discourse 側のすべての SSO レコードを削除し、次にユーザーがログインしたときに Discourse が SSO ペイロードのメールアドレスでユーザーを関連付けることができました。その後、Discourse はユーザーの新しい SSO レコードを生成しました。これはダミーのメールアドレスでも機能します。

DiscourseConnect 認証のロジックは、Discourse が最初にペイロードの external_id フィールドに基づいてユーザーを見つけようとし、ユーザーが見つからない場合はペイロードの email フィールドに基づいてユーザーを見つけようとフォールバックし、それでもユーザーが見つからない場合はエラーをスローします。

実際にライブサイトに実装する前に、これらすべてを再確認してください。ただし、ユーザーの実際のメールアドレスを Discourse サイトと共有できないケースでは、ダミーメールアプローチが本番サイトで使用されていることを知っています。

8

@simon 情報ありがとうございます！話が進んでいるようで嬉しいです。

これは問題ありません。以前にも、この「すべてのメールアドレスはユニークでなければならない」という問題に対する許容できる解決策として言及しました。この場合、実質的にメールを無効にし、ダミーメールを使用することは、この投稿をする前に私が考えた解決策です。

最初に明確でなかったかもしれませんが、この投稿の目的は、ログインプロンプトがユーザー名のみを受け付けるように強制できるかどうかを確認することでした。現在、ログインはユーザー名またはメールアドレスのいずれかで実行できます。メールログインがDiscourseのログインプロンプトで引き続き利用可能として表示されている場合、ユーザーは既存のアカウントのメールアドレスを使用しようとしてエラーに遭遇する可能性があります。そのため、ユーザーが現在のメールアドレスを使用しようとして失敗するのをただ受け入れるか、ユーザーに新しいフォーラム固有のメールアドレスを何らかの方法で通知する必要があります。どちらも混乱やユーザーの不便を引き起こす可能性があるため、理想的にはログインプロンプトをユーザー名のみを受け付けるように制限できることです。

残念ながら、スタッフがユニークなメールアドレスを持っていることも保証されていないため、それに頼ることはできません。この設定はメール送信のみを無効にするのでしょうか？それとも、ログインプロンプトで求めているような、メールの使用全体を無効にするのでしょうか？

DiscourseConnectのページを何度も見ましたが、このオプションは見つかりませんでした。このようなドキュメントを確認できる、より良い場所はありますか？その投稿には完全なドキュメントへのリンクが見当たらなかったので、そこにある情報がすべてだと仮定しました。

DiscourseConnectを実際に設定して設定を詳しく調べることはしていないことを認めます。ドキュメントがあれば、何が可能で何が不可能かを把握できると期待していましたが、そうすれば、コミットするまでテストインスタンス全体を設定する必要はないだろうと考えていました。しかし、何か明白なことを見落としたのでなければ、まだ簡単には利用できない情報があるようです。

これも以前の議論で検討されましたが、問題は、失敗したメールログインに対処するか、ユーザーにこの新しいフォーラムのメールアドレスを伝える必要があることでした。その摩擦を取り除くことが私の主な目標でした。Discourse自体をフォークすることなくそれが不可能であり、唯一の解決策が失敗したメールログインに対処するか、ユーザーに覚えるべき新しいメールアドレスを与えることである場合、別のフォーラムソリューションの方が良いかもしれません。

どうやら誤解していたようです。投稿自体からはあまり明確ではありません。しかし、私がそれを持ち出したのは、メールの一意性への依存を示すためであり、それは依然として問題となるでしょう。

これは、投稿だけでは絶対に明確ではありませんでした。何か見落としたかもしれませんが。その明確化に感謝します！それは私が望んでいたものにより近いように聞こえます。

9

メールでのログインが受け入れられると表示されているテキストを変更しましたか？すべてのテキスト文字列は上書きできます。

これは、まだ行っていない場合は、ドキュメントの良い候補となるでしょう。

テストサイトでこれらのシナリオを簡単にテストしたい場合は、たとえば bratwurst を使用できます。

「いいね！」 1
10

私の知る限り、Discourseのログインプロンプトにユーザー名フィールドのみを表示するように強制することはできません。また、そもそもユーザーを登録する方法を見つけるのに苦労することになります。だからこそ、DiscourseConnectを提案しているのです。

DiscourseConnectが有効になると、Discourseサイトの唯一の認証システムになります。ユーザーがDiscourseでログインボタンをクリックすると、discourse_connect_urlサイト設定に追加したURLに自動的にリダイレクトされます。そこからは認証システムが引き継ぎます。つまり、現在ユーザーがユーザー名とパスワードでログインできるサイトがある場合、ユーザーは引き続きその方法でログインすることになります。

これを設定するには、現在ログインしているサイトのバックエンドにコードを追加できる必要があります。設定はそれほど難しくありません。ここから良いサンプルコードを入手できます: https://github.com/discourse/wp-discourse/blob/main/lib/sso-provider/discourse-sso.php。このフォーラムでもヘルプを得ることができます。

現在のサイトにコードを追加できない場合は、ユーザーがユーザー名とパスワードでログインできる小さなウェブサイトを作成し、そのサイトにDiscourseConnectコードを追加することもできます。Discourseをフォークするよりも手間がかかりません。

「いいね！」 2
11

ありがとうございます！DiscourseConnectについて根本的な誤解をしていたようです。ログインページはDiscourseに残ったままで、外部サーバーに接続するだけだと思っていました。ユーザーが完全に選択した別のログインページにリダイレクトされるとは知りませんでした。

DiscourseConnectに関する私の誤解が、この問題と混乱の核心だったようです。

「いいね！」 2
12

通知用のメール送信を気にしないのであれば、SSOでDiscourseにgame-username@bogus.invalidというメールアドレスを付与することができます。

その後、ユーザーが2つ目の実際のメールアドレスを追加し、偽のアドレスをセカンダリに切り替えることが可能になるかもしれません。

13

申し訳ありません、昨夜の返信を見落としていました

していませんでした。前述したように、Discourseが使用可能であることがわかるまで、テスト展開を進めたくありませんでした。そのため、実際には何も試していませんでした。これまでは、機能について読んだり、不明な点があればここで質問したりしていました。そのように細かく制御できると聞いて、本当に素晴らしいです。その程度まで制御できるとは知りませんでした。

正直なところ、API以外の実際のドキュメントを見つけるのはかなり難しいようです。少なくとも初めてのユーザーの視点からは。

Discourseのホームページには、ドキュメントへのリンクを示すようなものは何もありません。DiscourseConnectのページにあるすべてのリンクは、無関係なページにリンクするか、投稿自体に戻ります。「Discourse documentation」を検索エンジンで検索しても、Documentation - Discourse Meta のようなページが表示されるだけで、これは単なるフォーラムのカテゴリであり、実際のドキュメントページではありません。また、https://docs.discourse.org/ も表示されますが、これはAPIドキュメントであり、DiscourseConnectのような機能に関するものは含まれていないようです。

この情報を有機的に見つけようとすることは困難であることが証明されました。

これらすべてが説明されている、見落とした明らかな場所はありますか？最も近いのはフォーラムのカテゴリのようです。スタッフなどがさまざまなトピックについて書いた多くのガイド/ハウツーがあります。しかし、フォーラム自体を文書化するために再利用するのは適切ではないと思いましたか？ Discourse APIのように、Discourseの機能/ツール専用のドキュメントソースはありませんか？

14

その通り、それは機能するでしょう。すでに数回述べたように、oauthプロバイダーからの偽のメールアドレスを使用することは、この投稿をする前に私たちがたどり着いたことです。

しかし、それだけでは「ユーザーがログインプロンプトでメールが受け入れられるのを見た場合、それらを使用しようとして、偽のメールアドレスのために失敗する」という問題は解決しません。

しかし、DiscourseConnectの仕組みについて誤解していました。私は、ログインフォームはまだDiscourse上にあり、Discourseが単にoauthプロバイダーに連絡するだけだと思っていました。@simonがそれを訂正してくれました。ユーザーが私たちの独自のログインフォームに移動するとは知りませんでした。それだけで、私が抱えていた問題はほぼすべて解決します。しかし、ありがとうございました！

「いいね！」 1
15

ホスティングの継続利用を意図しておらず、単に試してみたいだけであっても、トライアルサイトを自由に開始してください！気にしません！

このフィードバックをありがとうございます。改善に積極的に取り組んでいます。

さらに詳しいお話を伺うために、ご連絡してもよろしいでしょうか？

「いいね！」 2
16

私が一緒に仕事をした人々の中で、discourse.orgのホスティングに不満を持った人はいません。何らかの理由でセルフホスティングが必要な場合は、https://dashboard.literatecomputing.com/ にサインインして「無料トライアル」グループに参加し、ダッシュボードを無料で利用できます（無料トライアルグループへの参加方法がわからない場合は、私が提供できる以上のサポートが必要になるでしょう）。Digital Oceanとmailgunを使用する意思がある場合は、APIキーとホスト名を入力するだけで済みます。

17

私は恥ずかしながら、この選択肢を思いつきもしませんでした！それは良い点であり、テスト目的でそれに進む可能性が高いです。

今日早くにあなたのホスティングオプションを調べましたが、それはセルフホスティングよりも簡単でしょうが、残念ながら予算を大幅に超えています。200,000人以上のユーザーがいるため、「ベーシック」プランは選択肢ではありません。5人以上のスタッフがいるため、「スタンダード」プランは選択肢ではありません。そして、FOSSプロジェクトとして、私たちは寄付で運営しており、明かりをつけ、フルタイムの開発者1人を雇うのに十分なお金しか稼いでいないため、「ビジネス」プランは非常に手の届かないものです。

しかし、テスト目的でトライアルを使用することは素晴らしいアイデアです、ありがとうございます！私たちはすでにほとんどのサービスをセルフホスティングしており、Mastodonインスタンスまでセルフホスティングしているので、Discourseをセルフホスティングすることは大きなハードルではありません。

もちろんです！フィードバックを与えるだけでも、できる限りお手伝いできて嬉しいです。それが意図ではなかったことを明確にするために、あまりにも否定的になったように見えなかったことを願っています。

18

もしご興味があれば、一部のFOSSプロジェクト向けに無料ホスティングを提供しています…あなたのスタッフ数は私たちの制限よりも多いですが、決定を下す人々はそれを許容してくれるかもしれません。

（ここで「スタッフ」の定義は、「管理者」+「サイト全体モデレーター」であり、「それぞれの会社のスタッフ」ではありません。この前にあなたの頭の中でのスタッフの定義がどうだったか興味があります）

いいえ、丁寧で妥当でした :+1:t3:

「いいね！」 1
19

ありがとうございます！価格ページでこれを見落としていました。戻って確認したところ、ページの一番下にひっそりと記載されていました :sweat_smile: これを確認して、関係者と相談します！

この場合の「スタッフ」の定義は、2つの広い役割をカバーしています。

  • コア開発チームのメンバー（オープンソースプロジェクトなので、メンバーが出入りする可能性があり変動しますが、常に約5〜10人のアクティブな開発者がいます）
  • モデレーションチーム（開発者以外で、オンラインマッチやMiiverse実装、Discordサーバーなどのサービスをモデレートするコミュニティメンバー。これも変動します）

これを開発者5人に限定することも可能ですが、そうするとフォーラムでのフルアクセス権を持つ人を誰にするか決定する必要があります。また、フォーラムをモデレートできる人数も制限されます（そもそも開発者以外にモデレーションチームを導入したのは、この負担を軽減するためでした）。

必ず関係者にこの件を提起し、どうなるか見てみます！

20

TL4/Categoryモデレーターがここでかなりの助けになると感じています。

「いいね！」 2