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
07. Factory basics

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 we have social authentication working, but at the moment, it is tied down to just one service. Let's go over to our web root and just
00:07
take a look at what we have with these two controllers. So we know that we've set these up with a Twitter app to redirect back to callback, and redirect is responsible for generating the URL
00:17
to go over to X or Twitter. So what we have at the moment is a controller that's really just for authenticating with one service. Now, what we don't really want to do is duplicate this down
00:28
and then have different controllers for each service. There's not really a need to do that. So for example, we might have a slash GitHub one. We might have another one underneath this,
00:39
but we're going to end up with a bunch of controllers and pretty much the same functionality, just creating a user inside of all of these controllers. So what we're going to do in this episode
00:49
is we're going to look at a really basic pattern, which is the factory pattern, which will allow us to choose when we're coming back from that service which method of creating
01:00
the user we want to choose. Because at the moment, over in our auth callback controller, this is very specific to X. So let's take a look at this.
01:10
The first thing that we're going to do is change around the URLs, because we need to very easily be able to target specific services. So to do this, we're just going to have a service placeholder
01:21
inside of each of these URLs that we have here. So we're just going to say slash service. This is just going to be a string. So it's really as simple as accepting this service in
01:33
and then just replacing it out in here, and then just changing around the way that we redirect. So for example, over in social and index, we would just want to specifically
01:47
give the name of the service in here to build that route up and redirect properly. So that is going to work nicely. But when we come back from here, of course,
01:56
we've got a little bit more of a problem. We can accept in the service, like so. We can extract that from the service that we are being redirected back from.
02:07
But it's this point that we need to change around. OK, so we'll test this out really quickly. It's not going to work, because over on Twitter, what we're going to need to do is edit the redirect
02:19
URL that we have back here. So we're going to say slash Twitter. And we're going to save that out. And what we also want to make sure we do
02:26
is update the callback URL here as well that gets sent over to Twitter or X. OK, so let's just try this out. This is all going to work.
02:34
But then we're going to need to figure out how to specifically create a user for another service. So let's go and redirect back. And you can see, sure enough, everything is working.
02:42
OK, so let's now focus on this part here. So we always want to log the user in. And we always want to create a user. But this is the thing that we want
02:52
to dynamically do differently. OK, so let's take a look at the very basics of a factory just to see how this works. And then we'll implement this in the next episode.
03:02
So I'm going to go over to the main app directory. And I'm going to create out a factories folder in here. And then in here, I'm going to create out a create user factory.
03:13
This kind of involves social authentication. So you might want to change this over. But it's up to you. So I'm actually going to put this in a social directory
03:20
so it's a little bit more clear. And let's go ahead and start to build this factory out. So the namespace is now app and factories and social. And let's go ahead and say create user factory.
03:36
Now, before we implement anything inside of here, let's take a look at how we might want this to look when we're actually using this. And that will give us a good clue as to how this will be.
03:46
So I'm going to go ahead and just comment out everything we've got here. And in here, how do we want this to work? Well, we want to go ahead and grab the factory
03:55
and instantiate this. So we can just use the app helper for this. So create user factory, like so. Maybe we want to say something like for service
04:07
and then give the service in. Now, what this will do is it will return to us a class that's responsible for creating a user for that particular service.
04:16
So think of it like this. We do want to fill in a different column in the database. But we also might want to do something completely different
04:23
if we're authenticating with a GitHub user as opposed to an X or Twitter user. So we might want to do very specific things when we go ahead and create a user for a specific service.
04:35
So then after that, once that has returned to us the class that's responsible for creating that specific user for that specific service, we'll then want to create that user.
04:46
And to do that, we can pass in the user we get back from socialite. So that's pretty much what we want to end up with. That's going to return to us a user.
04:54
And then we can just pass that through to auth login. OK, let's take a step back and just look at this functionality first of all. OK, so we'll come over to our create user factory.
05:05
And we'll implement that method that we just decided. So that's for service. Now, that's going to get passed into it the service that we want to use.
05:15
And in here, we've got a couple of options. We could do a bunch of if statements. We could use a switch statement. But for this, I like to use a match statement in PHP.
05:23
It works really nicely for this use case. So we're going to go ahead and pass the service that we want to resolve in. And then in here, we can just give a kind of array type
05:33
structure to choose what we want to return. So for Twitter, I want to return a specific class that's responsible for creating the user. So this will be x create user class.
05:45
And we'll have others in here as well. So if GitHub was chosen, we would have one for GitHub as well. So let's just try this out and see how it looks.
05:54
Now, before we do anything here, there's a couple of things that we need to think about. We do need to return this value, whether it's a string or a class.
06:01
And we also need to provide a default value as well. So if, for example, we're trying to resolve a class for a service to create a user and it doesn't exist, we'll probably just want to throw a new exception in here.
06:14
So let's go ahead and do that. And we'll just say invalid service. It's really important that we include the default here, even if we just throw in an exception.
06:23
OK, so now what's going to happen is we will grab the factory. We'll call for service passing through Twitter. And that will return to us a string called x create user
06:35
class, or with the value x create user class. So let's go ahead and just die dump on what we get back from here. And then in the next episode, we'll
06:43
see the actual implementation of this. OK, so I'm going to go and just sign out here. And let's log in with x and see what we get when we return to our application.
06:53
And there we go. Now, if this was a GitHub callback, we would see GitHub create user class. So now what we can do from that is whichever
07:02
service we've chosen, we can create a user in a very specific way. So let's get rid of this die dump. And now that we've done that, let's head over
07:11
to the next episode and continue to work on this functionality. Now we've understood how this factory resolves a specific value for the service that we've chosen.

Episode summary

In this episode, we're starting to tackle the issue of making our social authentication system more flexible. Right now, we only support a single provider (like Twitter/X), and all our logic is crammed into its own controller, which is not ideal if we want to scale and add more social login providers in the future.

We take a look at our current controller setup and recognize that duplicating code for each provider (like adding separate controllers for GitHub, Google, etc.) would be messy and hard to maintain. To fix this, we introduce the factory pattern, which will help us dynamically pick the right logic for creating users depending on which service they're coming from.

The first steps include changing our routes and controller logic so that the service (e.g., twitter, github) is passed in as a parameter. This allows the system to know which provider we're working with, making our code more flexible.

After tweaking the routes and callbacks, we start scaffolding out a CreateUserFactory class. We think through how we'd like to use it: call CreateUserFactory::forService('twitter') and have it give us back a class that's responsible for user creation for that specific service. Inside the factory, we use PHP's match statement to map service names to their respective "create user" classes, and we make sure to throw an exception if a service doesn't exist.

By the end of the episode, the groundwork is set, and we do a quick test to make sure it's working—next time, we'll fill in the actual logic to create users for each provider!

So, if you've been wondering how to cleanly support multiple social authentication providers without messy duplicate code, stick around as we flesh out a neat solution!

Episode discussion

No comments, yet. Be the first!