ローカル開発専用です。本番サイトでは使用できません
Discourse をローカルで作業する際、さまざまなログイン方法をテストできるのは非常に便利です。多くの場合、実際の認証プロセスそのものに関心があるわけではなく、Discourse がさまざまな入力に対してどのように反応するかを知りたいだけです。例えば：
- メールアドレスが確認されていない場合はどうなるか？
- 認証プロバイダーがメールアドレスを送信しなかった場合はどうなるか？
- 認証プロバイダーがユーザー名を送信しなかった場合はどうなるか？
- メールアドレスは一致するが UID が一致しない場合はどうなるか？
- 外部認証を使用した場合、招待はどのように機能するか？
- ログイン画面はどのような見た目になるか？
- （これ以上挙げてもきりがありませんが、ご理解いただけると思います）
これまで、実用的な選択肢は「開発環境に実際の Google/Twitter/OAuth2 などの認証を設定する」ことだけでした。これは機能しますが、非常に手間がかかり、さらにさまざまな組み合わせをテストするために複数の Google/Twitter アカウントを作成し続けるはめになります。
そこで、より簡素化されたものを開発しました：
このプラグインをローカルにインストールすると、偽の認証プロバイダーが利用可能になります。Discourse にとっては、Google、Twitter、OAuth2、OIDC などの他のプロバイダーと同様に機能します。
ログインフローを開始すると、この画面が表示され、任意のデータを手動で入力できます。送信された値はクッキー経由で記憶されるため、同じ操作を簡単に繰り返すことができます。フィールドは Omniauth Auth Hash Schema に準拠しています。
これは ManagedAuthenticator システムを使用するため、データは user_associated_accounts テーブルに保存され、provider_name は developmentauth となります。
DiscourseConnect にも対応しています。試すには、プラグインをインストールし、enable_discourse_connect 設定を有効にするだけです。次にログインすると、DiscourseConnect のすべてのフィールドが使用可能な状態で表示されます。
次回認証関連の作業を行う際にぜひ試してみてください。改善点があればお知らせください 
これはこれまで発明された中で最もセキュリティが脆弱な認証プラグインです。そのため、本番環境での起動は拒否されます。機能させるには、
DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE環境変数を1に設定する必要があります。
これはこれまで発明された中で最もセキュリティが脆弱な認証プラグインです。そのため、本番環境での起動は拒否されます。機能させるには、