-
Notifications
You must be signed in to change notification settings - Fork 82
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
Local kratos email verification with mailslurper #1648
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1648 +/- ##
==========================================
+ Coverage 56.76% 56.85% +0.08%
==========================================
Files 224 224
Lines 15850 15826 -24
Branches 388 384 -4
==========================================
Hits 8998 8998
+ Misses 6847 6823 -24
Partials 5 5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Ahmad. Here are some comments, still need to test this out locally.
config: | ||
# The URL for verification emails are set through the link method | ||
# but we're using the code method, so we disable this method for usage. | ||
enabled: false | ||
# Set through SELFSERVICE_METHODS_LINK_CONFIG_BASE_URL | ||
base_url: http://localhost:3000/api/ory | ||
code: | ||
config: | ||
# and make sure to enable the code method. | ||
enabled: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, should we make an effort from here on to start copying in the documentation from the ory kratos website?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's very helpful for values that we know we will inject new values into such as this and the UI_URL
s. Fortunately their env naming matches the path of the yaml
but in upper case and with underscores. I think it's helpful to have the env var to be easily-copied, though
courier: | ||
template_override_path: /etc/config/kratos/templates | ||
smtp: | ||
connection_uri: set-through-env-arg-COURIER_SMTP_CONNECTION_URI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you able to set this dummy value because the environment variable overrides whatever we specify in the config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly, I think for dev mode, we should maybe just let it be the mailslurper url and add a comment as we do for SELFSERVICE_METHODS_LINK_CONFIG_BASE_URL
above. I will do this now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -0,0 +1,9 @@ | |||
Hi, | |||
|
|||
you (or someone else) entered this email address when trying to recover access to an account. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would make it less ambiguous for now what these emails are referring to if we refer to a "HASH account" rather than just "account". (this suggestion applies to most templates)
you (or someone else) entered this email address when trying to recover access to an account. | |
you (or someone else) entered this email address when trying to recover access to a HASH account. |
cc @nonparibus for thoughts on the initial phrasing here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed "HASH account" preferable.
I would like to do a big pass at all of our transactional email copy soon.
Not necessarily as part of this PR, but could we consider how we might centrally collect all of our transactional email text in one place?
This could be creating an index pointing to the relevant lines of files like this, it could be a single directory that contains the actual emails themselves, or something like else (better) entirely. Either way we're not well set up for this at the moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nonparibus for now all the kratos transactional emails are in this folder https://github.com/hashintel/hash/tree/e98a86be821317929dfaa15edfd255af51222726/packages/hash/external-services/kratos/templates
for emails that we will send through HASH, we have to consider what we do to either co-locate them together or make them easily searchable. For now I think this kratos grouping is a nice start
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just want to flag that this suggestion also applies to the remaining email templates (including email subjects). Let me know if you intend on addressing this @thehabbos007
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, missed that this was for all: f710e62
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks -- wasn't aware we had the dir already. This is great.
I don't know what ultimate best-practice looks like here, but I would be happy with either:
- somewhere I can go that links out to all the different collections of transactional emails (like this), provided we actually keep it up to date;
- a single directory in which we store all transactional emails from across the app.
My sense is the latter probably makes marginally more sense, and will be easier to track.
I'll review/update Kratos email copy in a separate PR. Please make any adjustments between the two of you that you think make sense in the meantime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that a single directory would make most sense, it may be difficult to do currently without knowing how we structure mails in the HASH api. I'll make an index that links to the email templates in-use from /packages/hash/README.md
where we already have a seciton on sending emails. Does that sound good for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…/invalid/email.body.plaintext.gotmpl Co-authored-by: Ben Werner <42802102+benwerner01@users.noreply.github.com>
}) | ||
.then(({ data }) => { | ||
setFlow(data); | ||
extractFlowCodeValue(data); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we programmatically submit the form when it is populated from the query params for the first time? This would prevent the user from having to click anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could, yes. But the reason to use these codes in the first place is to prevent mail apps to auto-open the links on the user's behalf. I appreciate that we'd gate this behind the /login
interface and not submit, but I think we're better off not automating it for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I hadn't considered that, let's keep it as is for now then.
Co-authored-by: Ben Werner <42802102+benwerner01@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Ahmad, this is working locally for me 👍
@thehabbos007 I got CI failing in #1644 after merging
I’ve removed a few |
🌟 What is the purpose of this PR?
This PR adds email verification flows to Kratos, configuring the
code
method and custom mail templates.There are some potential type issues with the kratos SDK for typescript, see ory/kratos#2943 which means the current implementation casts a type in a place where it isn't expected.
The current setup allows for verification through the UI, but it isn't neatly integreated/expected. I've included the UI scaffold for prettifying
🔗 Related links
🚫 Blocked by
🔍 What does this change?
📜 Does this require a change to the docs?
🐾 Next steps
🛡 What tests cover this?
none
❓ How to test this?
whoami
request contains a verified mail📹 Demo
mail_verify.mp4