我希望请求 Discourse 原生支持真正的本地无密码流程，而无需依赖 Microsoft、Google 等外部身份提供商。
据我所知，Discourse 目前已有部分相关功能，但尚未提供所需的完整配置组合。
现有功能
Discourse 目前具备：
- 本地账户
- 通过
enable local logins via email实现邮件登录链接/类无密码登录行为 - 可延迟设置密码的邀请流程
- 通过 OIDC / OAuth / SAML / DiscourseConnect 实现外部认证自动配置
但缺失的关键点是：基于邮件的本地登录仍与本地登录整体绑定，这意味着我无法清晰地实现以下组合：
- 允许本地邮件魔法链接登录
- 允许本地邮件魔法链接注册/新用户引导
- 禁止本地密码认证
这正是我所期望的组合。
使用场景
我希望 Discourse 能原生支持以下模式：
- 用户访问网站
- 用户输入邮箱
- Discourse 向其发送一次性/短时效的登录链接
- 如果用户尚无账户，Discourse 自动创建账户
- 用户完成登录
- 后续登录可沿用相同方式
- 除非管理员明确允许，否则无需本地密码
换言之：
本地账户
本地邮箱所有权验证
无需本地密码
为什么这很重要
目前，若希望实现无密码体验，最简洁的变通方案似乎是使用外部身份提供商。但这并非所有站点都适用。
原因包括：
- 并非每个社区都希望依赖 Microsoft / Google / Auth0 等服务
- 有些社区希望采用更简单、更注重隐私的本地认证流程
- 有些社区希望在不出售身份的前提下减少密码带来的摩擦
- 有些管理员希望支持那些不擅长管理密码但能熟练使用邮件链接的用户
Discourse 已通过邮件链接实现了无密码登录的先例，因此这更像是一种缺失的产品模式，而非全新概念。
我的请求
我认为可以通过解耦以下概念来解决该问题：
当前行为
enable local loginsenable local logins via email
期望行为
允许管理员独立控制：
- 是否允许本地密码登录
- 是否允许本地邮件链接登录
- 是否允许本地密码注册
- 是否允许本地邮件链接注册/账户创建
期望的设置模型示例
例如：
enable local password loginsenable local email loginsenable local password signupenable local email signup- 可选：
local email signup creates account automatically - 可选：
local email signup requires staff approval - 可选：
local email login link expiry minutes
具体设置名称未必如此，但核心概念应如此。
期望的用户体验
登录
用户应能选择：
- 继续使用密码登录
- 或 通过邮件发送登录链接
若密码登录被禁用，则仅显示邮件链接选项。
注册
用户应能选择：
- 使用密码创建账户
- 或 通过邮件链接创建账户
若密码注册被禁用，则站点应自动采用邮件链接注册。
为什么邀请流程不够
邀请流程有助于新用户引导，但它们与真正的本地无密码认证模式并不等同。
据我了解：
- 邀请主要用于接受/兑换
- 它们不是用户持续的登录凭证
- 会话过期后，用户仍需通过常规方式登录
因此，邀请流程虽相关，但无法完全解决问题。
为什么外部认证不够
是的，OIDC / OAuth / SAML 可提供无密码或基于 OTP 的体验，且 auth skip create confirm 在此方面帮助很大。
但这意味着站点现在依赖于第三方身份提供商。
对某些社区而言这没问题，但对其他社区而言，这带来了不必要的复杂性和依赖。
安全方面的思考
我意识到邮件链接认证存在安全风险，但 Discourse 已有相关模式，例如：
- 通过邮件重置密码
- 通过邮件链接登录
- 通过邮件接受邀请
因此，这并非从零开始引入基于邮件的控制验证概念。
合理的防护措施可包括：
- 短时效链接
- 严格的速率限制
- 一次性令牌
- 邮件链接登录后可选的二次验证（2FA）
- 魔法链接认证后更改邮箱/密码前的可选冷却期
- 管理员可查看邮件链接登录日志
总结
我请求在 Discourse 中引入一级本地无密码模式，其中：
- 用户通过证明对其邮箱的控制权进行身份验证
- Discourse 可基于该流程创建本地账户
- 管理员可完全禁用本地密码认证
- 无需依赖 Microsoft / Google 或其他 SSO 提供商
我认为，对于希望实现低摩擦新用户引导而不出售身份管理的社区来说，这将是一个非常实用的功能。