摘要
我们应该为 Discourse 添加标准化的身份验证日志系统，该系统存储所有已启用身份验证方法的身份验证事件，以进行分析和故障排除。
详细信息
我们将提供一个身份验证日志记录提供程序，所有身份验证系统都将挂钩到该提供程序并发送事件。
例如，本地登录提供程序可能具有以下（不完整的）事件列表：
- 来自 [IP] 的用户
fhqwhgads（不存在）的登录失败 - 来自 [IP] 的用户
supermathie的登录失败，已被速率限制 - 来自 [IP] 的用户
supermathie的登录失败，但提供了无效密码 - 来自 [IP] 的用户
supermathie的登录成功，提供了有效密码 - 来自 [IP] 的用户
supermathie的登录失败，提供了有效密码，但需要 MFA 才能继续 - 来自 [IP] 的用户
supermathie的登录失败，提供了有效密码，提供了无效的 TOTP 代码 - 来自 [IP] 的用户
supermathie的登录成功，提供了有效密码，提供了vault-work令牌的有效 TOTP 代码
依赖现有日志（Web 日志）的问题在于，除了速率限制的日志外，它们看起来完全相同（[200] POST /session HTTP/1.1）。日志中没有含义。
担忧
人们担心匿名事件会生成日志条目，以及如何平衡这一点与 SIEM 分析感兴趣的事件的检测，例如密码喷洒攻击。
记录所有内容意味着互联网上的任何人都可以填充您的日志……但关于这是否是问题，还有待商榷。请参阅下面的保留说明 - 也许失败事件在应用程序日志中保留的时间更短。
一个类似的问题也出现在一次性令牌日志上，例如通过电子邮件登录。不正确的令牌可能不值得记录，但重放的令牌绝对值得记录，无论是从 SIEM 和用户支持的角度来看。
问题
保留：永久保留？30 天？90 天？更早地清除匿名事件？
API 密钥身份验证：此处是否应记录带有无效用户或管理员 API 密钥的调用？可能应该 - 这将有助于调试。
应配置多少？例如，为所有提供程序打开调试日志，还是仅为某个提供程序打开？
实现注意事项
实现应足够灵活，允许将另一个事件存储提供程序添加到日志记录管道中。此类提供程序的示例可能包括原始日志文件、消息队列或 S3 存储桶。此类提供程序的具体细节超出了此主题的范围，但实现应足够灵活，以便插件可以注册以接收生成的日志。
背景
一位客户要求此功能，目的是将其事件馈送到他们的 SIEM，我们意识到这是 Discourse 的一个功能差距。
在内部讨论中，我们还发现这些信息对站点管理员和我们自己的支持人员很有用，因为身份验证日志可能位于各种地方，并且需要知道在哪里查找它们。这依赖于个人知识，而中央日志将大大减轻这种负担。
从 rails 控制台方便地查看这些日志对我们和站点管理员来说将是有益的。