[0:00] Hello guys, I continue my series of
[0:02] building a typical Laravel SAS. So today
[0:04] you will see a video number two from
[0:06] this new course on Laravel daily and
[0:09] topic of today will be sign in with
[0:10] Google and GitHub. So Laravel socialite
[0:13] but I will also show how to test it all
[0:16] locally. So generally in this course I
[0:18] want to get deeper into each subject
[0:21] that's why the videos are longer. So for
[0:23] example 13 minutes in this case which is
[0:25] not that typical for this YouTube
[0:27] channel. And also inside the course on
[0:29] Laravel daily, not on YouTube, you will
[0:31] get access to the repository from this
[0:33] lesson because now it's something
[0:35] actually created and built and something
[0:37] to analyze. So on YouTube, I will not
[0:39] publish the repository links. This will
[0:41] be for premium members of Laravel Daily.
[0:43] So subscribe to the membership. Anyway,
[0:45] let's get back to the content of signing
[0:47] in with Google or GitHub on top of
[0:50] LiveWire starter kit in this case. In
[0:52] this video, we'll talk about social
[0:54] login. Pretty typical function for every
[0:57] SAS. So someone could continue with
[0:59] Google or GitHub in our case. So we will
[1:01] add those features on top of the default
[1:04] livewire starter kit in this case. But
[1:06] the whole functionality is global not
[1:08] specifically about LiveWire. But I will
[1:10] show you how to add those buttons with
[1:13] Flux as well. But the main problem with
[1:15] such functionality in my experience over
[1:18] many projects is how do you actually
[1:20] test if it works? Because the hardest
[1:22] part is not to write Laravel code for
[1:24] this is to set up accounts, projects and
[1:28] credentials on Google, GitHub or other
[1:30] providers to make it all work together.
[1:33] So I will show you that in this video a
[1:35] bit later but for now we need to look at
[1:37] the main package that drives all that
[1:40] thing. I will zoom out. This is Laravel
[1:42] Socialite which can help you to login
[1:44] with GitHub, Google, Facebook or other
[1:47] providers. So in the documentation you
[1:49] may find the general instructions for
[1:52] how to set up the credentials and how to
[1:55] set up the authentication. So basically
[1:57] we need two URLs where to redirect to
[2:00] after someone clicks that button and
[2:03] also the call back from Google or GitHub
[2:05] to perform the user creation process. So
[2:09] first I will show you the code and then
[2:10] the demonstration how it works with
[2:12] Google and GitHub. And I already have
[2:14] written the code behind the scenes. To
[2:16] save you some time from watching me
[2:18] typing. This is my personal style, but I
[2:20] will explain it as thorough as I can. So
[2:23] first things first, we need to install
[2:24] Laravel socialite with just composer
[2:27] required. Nothing fancy here. Then we
[2:29] add those two rice that the commentation
[2:32] is talking about. We need to have
[2:34] redirect and we need to have call back.
[2:36] And in this case, since we are using
[2:38] multiple providers, this becomes a
[2:40] variable. Maybe in your case you're
[2:42] allowing just sign it with only GitHub
[2:44] or only Google then you may skip that
[2:47] one. And then we have socialite
[2:49] controller with that redirect powered by
[2:51] socialite driver redirect. Validate
[2:54] provider is a function inside. In here
[2:57] you just validate those providers that
[2:59] you support and then socialite takes
[3:02] care of where to redirect to and then if
[3:05] the signin is actually successful then
[3:07] it reaches the call back gets the user
[3:09] from the provider from that driver from
[3:12] GitHub or Google and then performs the
[3:14] eloquent operation first or create and
[3:17] then logs in the user and redirects back
[3:20] to homepage or dashboard. Now these
[3:24] columns are new in the database. So for
[3:27] that we have a new migration adding
[3:28] those fields both nullable both string
[3:31] to the users table and also optionally
[3:34] this is debatable. You may change
[3:37] password to nullable because in case of
[3:40] user coming from social network the
[3:42] password is actually non-existent and
[3:45] then in the down migration you may
[3:47] return it back to nullable false. Also,
[3:50] of course, in the user model, we need to
[3:52] add those as fillables. Then, in the
[3:55] register or login blade, we need to add
[3:57] those buttons to those URLs. I asked AI
[4:00] cla to generate those buttons for me,
[4:03] and the result surprised me from a good
[4:05] site. It generated flux button with the
[4:08] icon. You saw that visually, but I can
[4:11] show it again. This is a zoomed in
[4:12] version, but it looks really good in my
[4:15] opinion. Really clean. This is again
[4:17] livewire starter kit thing with flux by
[4:19] the same kale porzio creator of livewire
[4:22] but the main thing that you need to know
[4:24] is route socialite redirect with the
[4:26] parameter your button may be styled
[4:28] differently it may be a link it may be
[4:30] whatever what you need to use is these
[4:33] two routes and then all the other form
[4:36] for signin stays as it was form register
[4:40] with all inputs based on your starter
[4:42] kit. So we're just adding new
[4:44] functionality here. And for that
[4:45] functionality to work, we need to
[4:47] configure the providers. And this is
[4:50] where I get to demonstrating Google and
[4:52] GitHub how to create those projects and
[4:54] how to set up these variables. So in the
[4:57] config services or in fact wherever but
[4:59] services is a typical file where you
[5:02] would store the credentials for
[5:04] thirdparty applications and you may
[5:06] structure them however you want but I
[5:08] just structure provider and then three
[5:10] credential variables and then after you
[5:13] set up the projects on Google and GitHub
[5:15] you fill them in in yourv file important
[5:18] part if you work with a team or in fact
[5:20] even if you don't env.ample
[5:23] so there is a file env.ample example
[5:25] that comes from default Laravel with
[5:27] default values for a lot of things. And
[5:30] this is important if you add new
[5:32] variables here. That file is pushed to
[5:35] the repository for other developers to
[5:38] see what variables and with what
[5:40] specific variable names they need to add
[5:43] to their.env files locally. So just a
[5:46] general rule, if you're adding new
[5:47] values to yourv, don't forget to add the
[5:50] same keys with empty values or with some
[5:53] default values intov.ample
[5:55] because not pushed to the repository to
[5:58] the GitHub. It's ignored for a reason of
[6:01] course for security butenv.ample
[6:04] is the one kind of set of rules for
[6:06] other developers and various automations
[6:09] for remote servers. And now I will
[6:11] demonstrate it to you in action. So
[6:12] we'll set up Google project, GitHub
[6:15] project and we'll test the social
[6:17] buttons from our local server. How to
[6:20] create a project in Google console to be
[6:22] used as Google signin. So you go to
[6:25] Google cloud console cloud Google com
[6:27] and then you choose a new project. In
[6:30] this case I open project picker and I
[6:32] have a lot of old projects but I choose
[6:35] new project. I have zoomed that in and
[6:37] you choose the project name whatever
[6:39] Laravel SAS course for example. Now we
[6:41] should go to APIs and services and here
[6:45] we need to create our o consent screen
[6:48] and of course we need to pick our new
[6:50] project because for some reason it's not
[6:52] automatically chosen. So let's click get
[6:55] started and you fill in the form. The
[6:57] name of the application you click next
[6:59] audience external then contact
[7:02] information is how you get notified
[7:06] and I agree with terms. Continue create
[7:10] and then you need to create O client
[7:13] application type web application name
[7:16] same Laravel SAS course which will be
[7:19] visible to your users and then this is
[7:22] important authorized redirect URIs and
[7:25] here we need to add our call back URL
[7:27] from our routes web this one. So in this
[7:30] case it will be o Google callback but
[7:34] what would be the actual URL we cannot
[7:37] use test domain locally I'm working with
[7:40] my Laravel herd so the domain is SAS
[7:43] test but it's not accessible from
[7:45] outside from Google or whatever provider
[7:49] and you have a few options here first
[7:51] Google allows you to have local host as
[7:53] a domain so HTTP local host or also
[7:57] HTTP127001
[7:59] like home but in my case I haven't found
[8:02] how to do that on Laravel herd because
[8:04] Laravel herd expects test domains
[8:07] another option is of course deploy that
[8:10] project to some server staging server
[8:12] and then have the real URL from there
[8:15] and the final option is to use external
[8:17] service to provide you the URL two most
[8:20] popular ones are and grock outside of
[8:23] Laravel community or in Laravel
[8:25] community there's expose by beyond code
[8:28] and also the same authors of Laravel
[8:30] Herd. So in Laravel Herd, you just enter
[8:33] the exposed token and you get the URL
[8:36] and you can try it for free. This is not
[8:38] a free service and Grock isn't free
[8:40] either. But let's try to register and
[8:43] get temporary free URL for now for this
[8:45] video. So here I am inside of expose
[8:47] dashboard and I choose via Laravel herd
[8:50] and I have the token to activate and in
[8:53] my Laravel herd in expose I just paste
[8:55] the token and then if we go back to
[8:57] Laravel herd documentation we need to
[8:59] run her share. So I go back to my
[9:02] terminal and launch hurt share expose
[9:06] black Friday deal and yeah I have the
[9:08] public URL that I can use for Google
[9:11] signin and in the free version of expose
[9:14] you have 1 hour to use that URL as I
[9:17] understand and if you follow that link
[9:20] in the browser I see laravel project
[9:22] great so it works let's try to set up in
[9:25] the Google signin so authorize redirect
[9:28] URIs I paste that URL o Google call back
[9:34] like this and that's it create and we
[9:37] should get the credentials so we have
[9:39] client ID which we need to paste in our
[9:42] env file inv.example example we have
[9:44] these without values then I copy them
[9:48] into env at the bottom for both Google
[9:51] and GitHub and for client ID this is
[9:53] exactly what we need so I paste this
[9:56] long client ID then I was expecting
[9:59] client secret to appear here but for
[10:01] some reason it didn't and download JSON
[10:03] doesn't work for some reason so I will
[10:06] click around and look for client secret
[10:08] oh so this is the explanation starting
[10:10] in November viewing and downloading
[10:12] client secret will no longer be
[10:14] available. But I have a client secret
[10:16] here and I can copy that with a button
[10:19] and paste in here in client secret. And
[10:22] finally, callback URL should be the same
[10:24] as Google redirect. So this one here,
[10:27] let's try it out. Here I am in my SAS
[10:29] test. I click login or register doesn't
[10:32] matter. They both have that button
[10:34] continue with Google. And that continue
[10:36] with Google gets us to redirect URL. So
[10:39] this one off Google redirect. And let's
[10:42] see what happens. I click here, continue
[10:44] with Google, choose an account to
[10:46] continue to share it with expose. Okay,
[10:49] I choose my email, sign in to shared
[10:52] with expose. This is kind of the
[10:53] downside if you're using some provider
[10:55] for that URL and I got the error and
[10:58] yeah, I forgot one thing in our
[11:01] socialite controller when working with
[11:03] expose or nrock where URL is different,
[11:05] you don't have the same session of user.
[11:08] So for that you need to change that to
[11:11] stateless redirect like this and same
[11:15] stateless user here and let's try that
[11:19] again. Log in continue with Google
[11:22] account sign in. And yeah I seem to be
[11:26] on the dashboard logged in but without
[11:28] any styling which means on that URL npm
[11:32] install hasn't been executed and CSS
[11:34] doesn't work. But basically if no errors
[11:37] that means that we have logged in
[11:38] successfully. If we go to our SAS test
[11:42] we don't have that session active
[11:44] because the session is on that expose
[11:46] URL but we have tested that Google
[11:49] signin actually works. I know it's not
[11:51] ideal scenario probably ideal scenario
[11:54] would be your own URL on some staging
[11:56] server which you then put inv file here
[12:00] instead of localhost or in fact good
[12:02] reminder I should change that to SAS.
[12:04] test, but for now it didn't cause any
[12:06] issues. But yeah, my personal preference
[12:09] actually is to test Google signin or
[12:11] GitHub signin a bit later on staging
[12:14] server when the project is out of local
[12:16] environment. But I just wanted to show
[12:18] you how to do that locally if you do
[12:20] want to make sure that the function
[12:22] works correctly. Now let's try the same
[12:24] thing for Google account. So to have
[12:27] Google application you have to go to
[12:29] settings and then in settings down below
[12:31] you have developer settings and then you
[12:34] go to oth apps in this case I will be
[12:36] using my personal GitHub account poor I
[12:39] also have Laravel daily kind of a
[12:40] corporate but it doesn't really matter
[12:42] you just click new o app here and you
[12:46] fill in the form with name and URL that
[12:48] doesn't really matter this is more like
[12:49] formal things and callback URL this is
[12:52] what does matter and to get that URL I
[12:54] will again launch her share because I'm
[12:57] shooting this part of the video later
[12:58] than 1 hour. So I have a new shared with
[13:02] exposed domain name which should work in
[13:04] the browser as well. Good. So now I can
[13:07] put that into GitHub here in the
[13:09] callback URL should be O GitHub call
[13:13] back.
[13:14] We register the application and in this
[13:17] case it's easier than Google. So you
[13:19] have client ID right away. you copy and
[13:22] paste it intov
[13:24] redirect URI should be the new URL so
[13:28] it's not even in sync so this one will
[13:30] not work anymore and here we put o
[13:33] GitHub call back like this and then
[13:37] client secret from GitHub we click on
[13:39] generate a new client secret and then I
[13:42] have this new client secret to copy and
[13:44] paste and of course I will delete all
[13:45] those applications after this video is
[13:48] done so that's why I'm kind of safely
[13:50] exposing osing those credentials and now
[13:52] we can try out GitHub sign in. So here I
[13:54] am in my register form again continue
[13:56] with GitHub authorize. As you can see
[13:59] this is the application name we entered
[14:01] authorize and yeah again we are on that
[14:04] shared withexposed.com domain without
[14:06] CSS which means that actually it is
[14:09] working and another proof that it's
[14:11] actually working in our local database
[14:13] we have this. So I have the name from
[14:16] GitHub account, the email, O provider, O
[14:19] ID and basically we have a new user in
[14:22] local database.