Social Authentication with Laravel
This episode is for members only

Sign up to access "Social Authentication with Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
05. Updating the user table

Episodes

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

Transcript

00:00
OK, so let's prepare the database for storing this user.
00:03
And this might seem pretty obvious, but there's a couple of things that we need to think about when we're storing a user. Now, if we head over to the default migration
00:11
that we get with a fresh Laravel installation, the Create Users table, we already know that we've got a string in here which will store the hashed password. But at the moment, this isn't nullable,
00:22
which is really important for social authentication. We're not going to have a password for a user when we redirect over and store them from an account. So what we need to do is make this nullable.
00:34
Now, there's a couple of ways that you could do this. You could set this up if you have a new app with just modifying the initial migration and running that to create your app.
00:43
But I'm going to show you how you can modify this if you've already got a users table. We want to make this value nullable. Now, the other thing that we want to do here
00:52
is store the user's xID, their Twitter ID. So let's go ahead and work with that one first, because that's pretty straightforward. So we'll go ahead and make out a migration here.
01:03
And we're going to say add xID to users table. And that will create that migration for us. So let's open up the create or add xID to users table migration.
01:16
And this is pretty straightforward. I usually always store these as strings, even if they can be numbers. We want to just keep this really open to anything in the future.
01:25
So I'm just going to call this xID. And really importantly, for any service you create, you really want to make sure these are nullable, because of course, someone might sign up
01:34
with GitHub, in which case they won't have an ID for x. So let's go ahead and migrate this one. And that will be that one done. So let's run migrate.
01:43
Now, when we are adding these, we're going to head over to the user model. And we're either going to get rid of fillable altogether, or we're going to go ahead and add these into here
01:53
so they can actually be filled. OK, so the next thing we want to do before we start to create a user is make that password nullable.
02:01
So like I said, you can modify the original migration, or you can go ahead and change over properties of current columns in your database. So let's make a migration here.
02:11
And we're going to call this set password nullable on users table, or whatever you want to call it. So let's go ahead and run this. And let's head over to that migration.
02:21
And let's go down here. Now, we don't have some scaffolding here. So I'm just going to go ahead and grab the schema scaffolding for this.
02:28
And we want to modify this existing column. So let's go ahead and choose the string password column. We want to change this to nullable. And then all we do in here is just invoke the change method.
02:42
So what this will do is it will take the existing password, which is a string, add nullable on. And then by invoking change, this will go ahead and change that over.
02:51
Now, this doesn't work by default. So if we just go ahead and run php artisan migrate here, you'll probably see an error if you're not running doctrine debow.
03:01
Now, let's go over to our database and just double check to see that this is nullable. And it is. Now, if you see an error here, what you're going to want to do
03:10
is go ahead and install doctrine debow. So you just do a composer require doctrine slash debow if you're working with a Laravel version that doesn't already include this, or if you're changing
03:20
anything that requires this. So that's a really important point, because you may come across an error. So hopefully that helps.
03:26
OK, so we have changed over everything. And now we're pretty much ready to go. So when we come back from Twitter, we can store a name. We can store an email.
03:36
We can add that xid in here. But really importantly, we cannot store a password, because when we come back from here, we're not going to want to set the user's password.
03:45
OK, so we should be pretty much set up. Let's head over to the next episode and actually get this user created in the database when we redirect from one of these services.

Episode summary

In this episode, we're getting our database ready to store users who sign up or log in through social providers like Twitter. We start by looking at the default Laravel users table and realize there's a little problem: the password field isn't nullable, but social users (like those from Twitter) won't have a password to set. So, we need to tweak that!

First, we cover how to add a new column for storing the user's social provider ID—in this case, their Twitter (or "x") ID. We create a migration to add this as a nullable string column since not every user will have one (for example, someone who signs up with GitHub won't have a Twitter ID).

Next, we make the password field nullable as well. We walk through creating a new migration to update the existing table, since it's not a fresh install. There's a bit of an extra gotcha here: if you get a migration error, you might need to install the doctrine/dbal package to allow changing existing columns. Once that's done, we check that everything's good in the database.

To wrap up, we mention updating the User model so you can mass-assign these new fields, and now we've got everything set so we can actually store social users when they come back to our app. All set—next up, creating those user records!

Episode discussion

No comments, yet. Be the first!