Switching Exposed User IDs in Laravel Fortify Email Verification
Playing
01. Switching Exposed User IDs in Laravel Fortify Email Verification

Episodes

0%
Your progress
  • Total: 8m
  • Played: 0m
  • Remaining: 8m
Join or sign in to track your progress

Transcript

00:00
When you use Laravel Fortify or Laravel Jetstream which uses Laravel Fortify, with the email activation process when we first sign up, the email that we get sent does actually contain the user's ID. Now this is potentially a commercially sensitive piece of information
00:19
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
00:36
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.
00:51
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
01:06
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
01:20
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
01:35
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
01:49
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
02:02
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
02:16
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.
02:33
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
02:49
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.
03:06
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
03:22
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
03:36
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
03:51
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
04:07
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
04:21
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
04:35
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
04:51
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.
05:08
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
05:23
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
05:38
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
05:55
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
06:11
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
06:28
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
06:42
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.
06:58
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
07:15
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
07:33
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
07:46
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
08:06
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.

Episode summary

In this episode, we dive into a sneaky detail that comes up when using Laravel Fortify (or Jetstream, since it relies on Fortify) with email verification: by default, the verification email that's sent out includes the user's auto-incrementing database ID in the verification link. This might not sound like a big deal, but it can leak info about how many users your app has—something you might want to keep private!

First, we show exactly what this looks like by setting up a fresh Laravel Jetstream project and sending a registration verification email through MailTrap. Taking a close look, you'll see the user ID sitting right there in the URL.

To keep this info private, we walk through how to swap that exposed ID out for a UUID instead. That means creating a migration to add a uuid field to your users table, setting up your User model to auto-generate a UUID for each new user, and making sure that the email verification process uses this UUID in the URL instead of the default ID.

We also dive under the hood to show how Fortify builds its verification links and where you need to override behavior in your User model. The result: the email sent to new users now contains a UUID, so you’re no longer giving away your user count (or anything else sensitive) by accident.

Perfect for anyone looking to make their Laravel app a little more private and professional!

Episode discussion

No comments, yet. Be the first!