仅限本地开发使用。不适用于生产环境
在本地开发 Discourse 时，能够测试各种登录方式非常有用。大多数情况下，我们并不关心实际的认证流程，只需了解 Discourse 会对不同输入做出何种反应。例如：
- 如果邮箱未验证会发生什么？
- 如果认证提供商未向我们发送邮箱地址会发生什么？
- 如果认证提供商未向我们发送用户名会发生什么？
- 如果邮箱匹配但 UID 不匹配会发生什么？
- 使用外部认证时，邀请功能如何运作？
- 登录界面长什么样？
- （我可以一直列举下去……但你懂的）
到目前为止，唯一的实际选项是“在你的开发环境中配置真实的 Google/Twitter/OAuth2 等认证”。这虽然可行，但极其繁琐，而且你不得不创建多个 Google/Twitter 账号来测试不同的组合。
我制作了一个更精简的方案：
如果你在本地安装此插件，它将提供一个伪造的认证提供商。对 Discourse 而言，它的工作方式与其他任何提供商（如 Google、Twitter、OAuth2、OIDC 等）完全相同。
当你启动登录流程时，将看到此界面，你可以手动输入任意数据。提交的值会通过 Cookie 被记住，因此你可以轻松重复相同的操作。这些字段对应于 Omniauth 认证哈希模式。
它使用 ManagedAuthenticator 系统，因此数据将存储在 user_associated_accounts 表中，其 provider_name 为 developmentauth。
它还支持 DiscourseConnect！要尝试此功能，只需安装插件并启用 enable_discourse_connect 设置。下次登录时，你将看到所有 DiscourseConnect 字段已准备就绪。
下次处理认证相关工作时，请尝试使用它，并告诉我有哪些地方可以改进 
请注意，这是迄今为止发明过的最不安全的认证插件。因此，它将在生产环境中拒绝启动，你必须将环境变量
DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE设置为1才能使其正常工作。
请注意，这是迄今为止发明过的最不安全的认证插件。因此，它将在生产环境中拒绝启动，你必须将环境变量 