改进集成身份验证开发的建议

贡献 功能
1

正如 Jeff Atwood 所说，电子邮件是 Discourse 的核心，我们不应也无法忽视或绕过它。

但现实世界可能比我们要想象的更复杂，有些平台并不提供电子邮件地址，而我们仍希望将其集成到 Discourse 中。discourse-oauth2-basic 解决方案是：

discourse-oauth2-basic 是一个通用的 OAuth2 插件，因此未包含针对特定平台的功能。但当我们开发特定平台的身份验证器且不提供电子邮件地址时，我们可能希望集成该平台的通知系统，而不是默认的电子邮件通知。

我建议的解决方案是为唯一身份构建一个伪造的电子邮件地址，例如 平台前缀 + 平台 ID@yourdiscours.com，并实现一个电子邮件验证器来决定应使用哪种通知系统，或者通过钩子和过滤器在发送通知时构建发送者，可以选择默认电子邮件通知或已实现的验证器。我认为这是一种对现有架构非侵入式的实现方式。

1 个赞
2

这完全可行。例如，你可以使用 Steam 登录（不提供电子邮件），在插件的修改版本中设置虚拟电子邮件，并利用原生推送通知（支持 Windows、macOS、Linux 和 Android）来满足所有通知需求。

与特定平台集成时，始终需要进行一些定制开发。Discourse 已有部分客户采用类似方案并取得了巨大成功，他们中的一些是目前规模最大的实例！

4 个赞
3

是的，但 Discourse 似乎是通过硬编码直接调用 Email::Sender 来发送导出通知，而不是像 DiscourseEvent 那样触发通知事件钩子。

那么，如何将通知“重定向”到我们的自定义通知系统？是否有公开的示例？

1 个赞