and you might not want to use this ID in that email. What this essentially means is whoever sees this knows how many users you potentially have in your database. When we use the ID we know that most of the time it's auto incrementing so that will then reveal potentially how

many users you have in your database. You might not want that to be the case. So whether you're using Laravel Fortify on its own or you're using Laravel Jetstream, I'm going to show you in this snippet how to swap this out for something else like a UUID.

Now before we start let's just demo this out so you can see exactly what I mean and if you want to switch this over you can. Now the only thing I've done is set up a fresh Jetstream project. I've changed over the database that we're using just here and I've also hooked this up

to MailTrap which is just a fake email inbox service and all of the emails that our app sends will land in here. Now just before we get started let's make sure that we have email activation enabled. So the first place to do that

is in config and fortify. We can go ahead and enable email verification and the second thing that we need to do is over on the user model make sure we implement the must verify email trait that will trigger

that email to be sent. So let's go back over and just register an account and see what we mean. So let's enter all of the information that we need here and go ahead and hit register. Okay so we're registered

and we should have received a verify email address email. This is the link that we want to be careful with. So if we just copy this over and just paste this in here, sure enough the user id is present in this url. That's what we

want to change. That then potentially tells us how many users are in the database. So let's go and just close this off and just start to look at how we might switch this up. Now it really depends on what you

actually want to replace this with. I'm going to replace this with a uuid but of course you can choose pretty much anything. Let's just start by deleting the user from the database and we'll go ahead and run a migration or create a migration here to add a uuid to the users table.

And again you can switch that out for pretty much anything that's safe for a url. So let's go ahead and do that now and add that uuid in there. So let's open up add uuid to users table and let's come down and add this in. So uuid, we're going to call that

uuid. Let's go and make that unique and of course we'll drop this on the down migration. There we go, great. So let's come over and run php artisan migrate and that's how uuid added to the users table.

Now a little bit of background if you've not worked with fortify too much. When we create a new user that will of course validate and actually create the new user. You could add into here the uuid generation but what I find a little bit more useful is doing this

directly within the user model. That means that anywhere that we actually create this user this uuid will be assigned. So to do this we can create a static function out that's invoked once this model has been booted. So we can call that

in there and we just want to hook into eloquent and say that when we are creating this particular record assign the uuid. So we'll get into here a user. You don't need to type in this but I'm going to go ahead and do that and just

import the class anyway. So on the creation of this as it's being created let's take that user and assign a uuid. Now laravel string helper allows us to generate a version for uuid so we can just go ahead and import that class from illuminate support string

and use that in there. So now when we register a user that uuid will be assigned. Let's just test that out before we do anything. So let's come back over to register and re-register an account in here and let's go ahead and submit that through

and we just want to check our database just to make sure that got added in there and it did. So I'm going to delete that user once again because of course the goal here is to register and actually get that proper email sent through. Of course this one still

has the id in there. Now to tackle this problem we're not just going to implement the solution. We're going to kind of dive into how this works behind the scenes. So if we open up the fortify routes file within the vendor package let's go down here to the email

verification set of routes. So you can see here that we've got under that route that we get sent through or generated the id. Now if we open up verify email controller and we come down to the verify email request. Let's open that up.

Sure enough that's just directly using that id in there so that's what we want to switch over. So that id gets sent in and used to actually look that user up to verify their account and by verify if you are very new that means set email verified at

to the current date and time. So the way that this works is if we open up the user model we implemented the must verify email trait. Now along the way what happens is we get this send email verification notification method invoked

which notifies the user on the email channel and that sends that email. So verify email if we open that up is exactly what we're looking at here. So this is just a laravel notification which returns mail as the channel so that obviously emails us

and then just down here when we're kind of building this url up which is assigned here calls this verification url method. Now this is where we want to look because this is how the root is built up to actually redirect us back to the app

from that email and this is the id that we are using e.g. the user's auto incrementing id. Now what this will use here is notifiable which is the user and get key. So get key is a method over on our models

which return to us the key that we want to use to identify the user. Now we have to be careful with this because if this is used anywhere else you could potentially break something but basically what we want to do is override get key and for the user we want to say

i want to identify this user by the uuid not the id. If we just open up the base model really quickly and have a look at the get key method or we could look at the get key name method you can see that it returns this primary key.

If we look at the get key function by default that grabs an attribute from this model by the key name that we've defined so we can pretty much just override this or get key name to make this work. So let's go over to our user model

and go ahead and create our get key and let's just return in here this uuid. So now what's going to happen is when this notification is sent and when the verification URL is generated rather than just use the default we're now overriding

the get key method which returns to us the uuid. Like I said this gets used in other places as well so just keep an eye out for that but let's give this a spin and see what it does now. So let's go ahead and re-register an

account and hit register, wait for that email to get sent and we should now see if we grab the link for this the uuid in there being used instead of the id. Now this is still going to work because we're still clicking through taking that looking the

user up by that uuid and sure enough we're now verified. So there is a quick and easy way to not expose the amount potential amount of users you have in your database by exposing that id when your users verify their email.