Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

courier: Implement message templates and SMTP delivery #146

Merged
merged 4 commits into from
Dec 10, 2019
Merged

Conversation

aeneasr
Copy link
Member

@aeneasr aeneasr commented Dec 10, 2019

This patch adds a message templates (with override capabilities)
and SMTP delivery.

Integration tests using MailHog test fault resilience and e2e email
delivery.

This system is designed to be extended for SMS and other use cases.

Closes #99

closes #99
This patch adds a message templates (with override capabilities)
and SMTP delivery.

Integration tests using MailHog test fault resilience and e2e email
delivery.

This system is designed to be extended for SMS and other use cases.

Closes #99
@aeneasr aeneasr added this to the v0.0.1 milestone Dec 10, 2019
@aeneasr aeneasr self-assigned this Dec 10, 2019
@aeneasr aeneasr merged commit dc674bf into master Dec 10, 2019
@aeneasr aeneasr deleted the fix-99 branch December 10, 2019 17:39
@merlindorin
Copy link

@aeneasr why this implementation focus on smtp and not on a generic approach like a notification webhook?

With a webhook, we are implementation "free" and it will be easy to cover cases like "sms", "telegram notif" or whatever... maybe it's on the roadmap?

@aeneasr
Copy link
Member Author

aeneasr commented Oct 19, 2020

Because webhooks would require a specific format depending on the upstream service (telegram works different from whatsapp from facebook from ...). SMTP and email are standards however.

But the general idea is to support multiple senders here (SMS for example) and maybe stuff like AWS SNS or similar.

@merlindorin
Copy link

I was more thinking about a generic webhook that require an external adapter that will talk, if necessary, to an external service. The main goal is to be free of ory implementation (smtp, template, etc.) and do what we need through a custom service. In that case, we only need to be able to read json in order to set the execution context and do what we want.

For example:

+-------------------+    +---------+    +--------------+    +-------------+
| user registration +--->| webhook +--->| email-sender +--->| smtp server |
+-------------------+    +---------+    +--------------+    +-------------+

Thank you for the quick reply :) <3

@aeneasr
Copy link
Member Author

aeneasr commented Oct 19, 2020

Yeah a generic webhook also makes sense, but it would obviously increase the amount of time required to adopt ORY Kratos as one would have to implement the email adapter. I generally think though that a generic webhook additionally to SMTP would be a good idea! Would you be open to create an issue for that, or -� even better - make a contribution towards this? :)

@merlindorin
Copy link

Clearly, it's more complicated for a quick use. Will open an issue... not sure I will have enough time for a contribution. thx again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

hermes: Notification architecture
2 participants