Suggestion for improving Integrated Authentication development

As Jeff Atwood said, email is the core of Discourse and we shouldn’t or we can’t ignore and bypass it.

But real-world may unruly than our imagining, some platforms are not provided an email address and we also want to integrate it to our Discourse. The discourse-oauth2-basic solution is

The discourse-oauth2-basic is a general-purpose OAuth2 plugin so didn’t include any feature for a special platform, but when we develop a platform-specific authenticator and don’t provide an email address we may want to integrate the platform notification system instead of the default email notification.

My suggested solution is to build a fake email address for unique identity like platform-prefix + platform-id@yourdiscours.com, an email validator to decide which notification system should be used or some hooks and filters to build sender when sending a notification, the default email notification or authenticator implemented. I think it’s a non-invasive implemented for exist architected?

1 Like

That’s completely doable. For example you can have Steam login (which provides no email), set fake emails in a forked version of the plugin and use native push notifications ( available in Windows, Mac OS, Linux and Android) for all notification needs.

It will always need some custom work to integrate with the specific platform, and at Discourse we have some customers using a setup like that to great success. They are some of the biggest instances out there!

4 Likes

Yes, but Discourse seems to send export notification via Email::Sender directly by hardcode rather than invoking notification event hook, like DiscourseEvent

So how to “redirect” notification to our custom notification system, any public example?

1 Like