Implementing Email Change Verification
00:00 So let's go to the profiles change email route here. And right down here is where we need to get all this information from the prepare verification. So let's do that. Const OTP redirect URI verify URL
00:17 equals prepare verification from our verify util. And for this one, it's going to be pretty similar to the ones we've done already. So the period is going to be 10 minutes, 10 times 60. And we'll send along the request. The target will be the user ID. That's the email that we're trying to change.
00:37 You wouldn't want to use the email, because that's, well, I suppose you potentially could, but probably best not to, because we need to be able to use this target to find something that's in our database. And if we use the new email, that new email is not in our database yet. So yeah, the user ID is probably the best thing.
00:55 You could potentially use the username as well. But user ID, we've got it. So we may as well use it. And then our type is going to be a new type. So let's dive into our verification types right here and add a change email type right there. Great.
01:12 And so with this change email type, oh, and actually, you notice the TypeScript is complaining about this. That's because we need to handle this action. Where's our action? Right down here. So we need to add another case for change email.
01:28 And this is going to return handle change or handle verification from change email. And then we'll rename that to handle change email verification, just to distinguish between the different types. And now TypeScript is happy. So we've got all of that verification stuff.
01:48 We can get rid of this. I have a feeling I misspelled something. Yeah, redirect to. There we go. OK, then this user ID, this is, oh, right. We need to await this. I was like, why is this giving me underlines? But see, TypeScript, I'm telling you folks, if I hadn't been using TypeScript,
02:07 we wouldn't have gotten that underline and we'd be in trouble. OK, so this cannot find the user ID. We need to get that right here, user ID. There we go. So we already were requiring that they're logged in. But now we need that value. There we go. OK, so then we send the email. We already have an email set up for that and all that.
02:27 So now we need to stick the new email address in the verify session so that we can check that when they come back.
02:38 So let's grab verify session is await verify session storage dot get session request headers get cookie.
02:56 And then we're going to get or set verify session dot set the new email address session key, which we got up here, to the email address that they provided. So that'll be our submission value email. There we go. And then we can commit that here.
03:13 So set cookie and await. Yeah, verify session storage. I hope by the time you're watching this or sometime in the near future, Copilot finally learns how these APIs work because it's super annoying. OK, great. And then we're all set as far as this is concerned.
03:33 We still have to handle verification and all of that, which we will do soon. But we will at least send the user where they're supposed to go. So if I say cody at example.com, then I go to verify. I get my type correct in there. I get my log right here.
03:50 And so if I submit this, then we should get an error. We'll implement this soon. So that's the next thing we're going to be doing. So in review, actually not a whole lot different here. We get the user ID. We create a verification that gets us our redirect to and our verify URL and our one time password.
04:09 We send that along to our email that we send to the user. And then we stick the new email address in the verify session so that when the user comes back, we can verify that new email address is the one that they are confirming.
04:26 And that is part of the solution to this overarching feature request that we've got.