統合認証の開発を改善するための提案

貢献 特徴
1

Jeff Atwoodが述べているように、メールは Discourse の中核であり、無視したり迂回したりすべきではありませんし、できません。

しかし、現実世界は私たちの想像よりも厄介な場合があります。一部のプラットフォームではメールアドレスが提供されておらず、それでも Discourse と統合したいというケースがあります。discourse-oauth2-basic という解決策は、

discourse-oauth2-basic は汎用 OAuth2 プラグインであるため、特定のプラットフォーム向けの機能は含まれていません。しかし、プラットフォーム固有の認証機能を開発し、メールアドレスを提供しない場合、デフォルトのメール通知ではなく、そのプラットフォームの通知システムを統合したいと考えるかもしれません。

私の提案する解決策は、一意の識別子として「フェイクのメールアドレス」（例：platform-prefix + platform-id@yourdiscours.com）を作成し、どの通知システムを使用するかを決定するための「メールバリデーター」、あるいは通知送信時に「送信者」を構築するためのフックやフィルターを実装することです。これにより、デフォルトのメール通知または実装された認証機能を使用できます。これは、既存のアーキテクチャに対して非侵襲的な実装方法だと考えています。

「いいね！」 1
2

それは完全に可能です。例えば、メールアドレスを提供しない Steam ログインを使用し、プラグインのフォーク版で偽のメールアドレスを設定し、すべての通知要件に対してネイティブプッシュ通知（Windows、Mac OS、Linux、Android で利用可能）を使用することができます。

特定のプラットフォームと統合するには、常にいくつかのカスタム作業が必要になりますが、Discourse では、そのような構成を採用して大成功を収めている顧客が複数います。彼らは現在存在する最も大規模なインスタンスの一部です！

「いいね！」 4
3

はい、しかし Discourse は、DiscourseEvent のような通知イベントフックを呼び出すのではなく、ハードコードされた Email::Sender を介して直接エクスポート通知を送信しているようです。

では、通知をカスタム通知システムに「リダイレクト」するにはどうすればよいでしょうか？公開されている例はありますか？

「いいね！」 1