update email link custom flow guide #1433
Conversation
|
Hey, here’s your docs preview: https://clerk.com/docs/pr/1433 |
Co-authored-by: victoria <[email protected]>
Co-authored-by: victoria <[email protected]>
|
Let me know if you need me to test the code @alexisintech -- I can't until Wed or Thurs this week. |
yeah I would appreciate :) we've done all these custom flows together, so I trust you to test these out! 🫶 |
| We take care of the boring stuff, like efficient polling, secure session management, and different device authentication so you can focus on your application code. | ||
| 1. On the [**Email, phone, username**](https://dashboard.clerk.com/last-active?path=user-authentication/email-phone-username) page of the Clerk Dashboard, next to **Email address**, select the settings icon. A modal will open. | ||
| 1. Under **Verification methods**, enable the **Email verification link** option. By default, **Require the same device and browser** is enabled, which means that email links are required to be verified from the same device and browser on which the sign-up or sign-in was initiated. For this guide, leave this setting enabled. | ||
| 1. Because this guide focuses on email links, uncheck the box for **Email verification code**. |
There was a problem hiding this comment.
This is the approach I was alluding to above.
|
|
||
| If you would like email links work on any device, make sure the [**Require the same device or browser**](/docs/security/email-link-protection) setting is _off_. When this setting is disabled, there's no constraint on where the link can be opened. For example, a user could try to sign in from their desktop browser, but open the link from their mobile phone. In this scenario, _the user's sign in would be completed on the desktop browser from which it was initiated, not the mobile phone where it was verified_. As a result, the user would be signed in on their desktop, not their phone. | ||
| ## Enable email link verification |
There was a problem hiding this comment.
Minor nit, but I think of the order of operations as a sign-up (verification) and then sign-in (authentication). I would swap the order to reflect that.
There was a problem hiding this comment.
you have to enable an authentication option before you can configure the verification option
There was a problem hiding this comment.
I have Email enabled and required, and Email verification link enabled. This is while the Authentication strategies -> Email verification link is disabled.. I can even disable 'Sign-in' inside of the email settings modal. This enables email link for sign-up, but fully disallows it for sign-in (not that I'm recommending that of course).
There was a problem hiding this comment.
that's a backwards approach though. you'd have to enable email as an identifier. then you'd have to go into the settings cog, disable for sign-up, and then disable email code verification and enable email link verification.
we're gonna tailor this towards conventional practices - a user enables email as an identifier. they need to disable email code verification and enable email link verification.
There was a problem hiding this comment.
that's a backwards approach though. you'd have to enable email as an identifier.
I'm not suggesting that at all. I am just suggesting swapping the order, because a developer is likely to want to consider sign-up(verification) and then (sign-in).
The point I was making is that you do not need email link authentication enabled to setup email link verification, so that's not a limit in swapping the order here.
a user enables email as an identifier. they need to disable email code verification and enable email link verification.
Yes, correct. Again, I'm not suggesting we don't do that.
There was a problem hiding this comment.
bear with me i'm just confused
There was a problem hiding this comment.
let's call on monday so you can just show me in a call what you're suggesting! because i think its getting lost over translation
|
|
||
| export type VerificationStatus = | ||
| | 'expired' | ||
| | 'failed' | ||
| | 'loading' | ||
| | 'verified' | ||
| | 'verified_switch_tab' | ||
| | 'client_mismatch' |
There was a problem hiding this comment.
I opened a SDK ticket to get this properly exported. I don't like recreating the type here.
|
|
||
| const { handleEmailLinkVerification, loaded } = useClerk() | ||
|
|
||
| async function verify() { |
There was a problem hiding this comment.
This may need to check/handle verified_switch_tab. I didn't test enough to know though. Same for sign-in/verify/page.tsx
There was a problem hiding this comment.
what does it mean, like when would this come up? I used two different tabs and this never came up for me
There was a problem hiding this comment.
I'm not sure off hand -- I didn't dig into it. That might be a question for SDK. I dropped my comment as I saw that was a possible status but wasn't mentioned or handled in the code.
| // OPTIONAL: This check is only required if you have | ||
| // the 'Require the same device and browser' setting | ||
| // enabled in the Clerk Dashboard | ||
| if (verificationStatus === 'client_mismatch') { |
There was a problem hiding this comment.
I received verify?__clerk_status=client_mismatch with same computer/browser. I'm going to check with SDK tomorrow(Friday) about this.
Important
🔎 Previews:
Explanation:
https://linear.app/clerk/issue/DOCS-5240/httpsdocs-preview-702clerkpreviewcomdocscustom-flowsemail-links
This PR: