All right, let's move on to authentication. So I'm back on the dacy UI components list and you'll see that there's an option for field set and this will allow us to quickly scaffold a login form or a registration form as you see right here. So I'm gonna grab this and now let's switch back. And why don't we begin within our routes file, right down here at the bottom. Let's listen for when the user visits, the register page, and for the controller name.

Let's listen for when the user visits, the register page, and for the controller name. Once again, be creative, name it whatever you want. I've seen off controller in the wild, I've seen registration controller, I've seen register controller, I've seen, um, make user controller. Uh, one I often do is registered user controller. Um, this kind of fits my restful, uh, tendency. I'm gonna create a new registered user.

Um, this kind of fits my restful, uh, tendency. I'm gonna create a new registered user. Next I could have one to say, well, when you submit that form on the registration page, then I'm going to post to the store action. I'm gonna store and persist a new registered user. So that kind of fits my head, but name it whatever you want. Alright, so let's go ahead and generate this controller. PHB Artisan Make Controller. And what should we name it? Well, why don't we put it within an auth folder

PHB Artisan Make Controller. And what should we name it? Well, why don't we put it within an auth folder and I'm gonna call it registered User Controller. All right, uh, what do we want here? Let's just keep it empty for now. Okay, so you can see it's smart enough to parse this and create a new auth folder for us. So that means if I open up the sidebar, sure enough, we have HTTP controllers off, and here is our new registered user controller.

we have HTTP controllers off, and here is our new registered user controller. Okay? So like we said, we're gonna show a form to create a new registered user. So that would take the form of something like this, um, form off that register. That looks good to me actually. And next, just a quick aside, because I'm using Peach B Storm and the Laravel idea plugin,

because I'm using Peach B Storm and the Laravel idea plugin, which is free, I can do things like this. I can press option return and quickly generate the view. So if I open the sidebar, you can see, yep, it figures out exactly what the path should be. So it's a, it's a nice little time saver. Alright, so let's do our layout register form here. Okay, so if we come back to our routes file, I can import this

Okay, so if we come back to our routes file, I can import this and now we can see we have two new endpoints to register and then persist a new, uh, registered user. Alright, so now if we come down here, the store action and we'll just say, um, create the new user and log them in our little to-do item there. Alright, this looks good to me. So let's see it in the browser. Alright, So here is our very simple layout

So let's see it in the browser. Alright, So here is our very simple layout and sure enough, in the nav bar we already have a register button. So let's do that. Now let's go into the nav component we created. And actually, very quickly, why don't we increase this background color and then get rid of that shadow. Alright, next, scroll down and here is our register link.

and then get rid of that shadow. Alright, next, scroll down and here is our register link. And that's gonna send us once again, to that new register endpoint that we created. So now if I come back and give this a refresh, yeah, it's a little darker, there's no shadow. And now we have a register button. And you know what? Why don't we say button primary? Alright, we're gonna go with that color, I guess. So I'm gonna click on it now,

Alright, we're gonna go with that color, I guess. So I'm gonna click on it now, and that takes us to our new registration form. All right, very cool. Alright, so now we can visit our register view, and I'm gonna paste in that, uh, field set component that we copied from the DCUI website. Let's paste it in and take a look at what we have currently. All right, that looks okay. Uh, why don't we tweak this a little bit? Why don't we set margins to auto good?

Uh, why don't we tweak this a little bit? Why don't we set margins to auto good? And then this is not our login form, this is actually going to be our register form. Alright, so to register, what do we need? Well, let's do this. Let's go to the migration that Laravel includes when you install the framework. And we can see that in order to create a user, it needs a name, an email address, email verified out would be handled behind the scenes.

it needs a name, an email address, email verified out would be handled behind the scenes. So just a password, email and name. But don't forget this is not set in stone. So for example, if you want this to be like the username rather than John Doe, um, then tweak it. You're in charge here and you can modify any of this stuff here. Okay? Anyways, name, email, password, let's remember that.

and you can modify any of this stuff here. Okay? Anyways, name, email, password, let's remember that. So let's switch back. Give us your name, please. This will be name, this is a standard text input, which by the way is a default. And then we'll say your name. All right? Let's do another one for, uh, email. And this will be your email, uh, email and then type this email, uh, that offers a few bells and whistles when you're filling it out.

and then type this email, uh, that offers a few bells and whistles when you're filling it out. So let's see, how are we doing? All right, so we have your name, we have your email, we have a password. This is looking good. Type to set the password. This all looks great. We have a little margin. I'm happy about this. Okay, so now actually, no I'm not. We're gonna say register. Okay, so now when we click this button, where are we going?

We're gonna say register. Okay, so now when we click this button, where are we going? Well, we already figured this out, right? We're gonna make a post request to this register endpoint. All right, let's do it now. So at the very top, we're gonna have our form, the action is gonna go to register. The method is going to be post, I do want CSRF protection. And uh, yeah. So now if we submit this notice,

And uh, yeah. So now if we submit this notice, we don't have any client side validation in place. So it will submit the form, at least I think there it goes, had to refresh and uh, sure enough we hit that end point. Okay? So yeah, just keep in mind you, you want some client side validation as well as server side, right? So in situations like this, you could say no, you have to give us your name, sorry, you have to give us an email

So in situations like this, you could say no, you have to give us your name, sorry, you have to give us an email and you have to give us a password. So now at the very least, if the user doesn't fill this out before we even reach the server and perform our second server side layer of validation, we get some free browser validation, uh, out of the box. Cool. So now I could do John Doe, john@example.com password. And when we submit this, now let's switch back.

john@example.com password. And when we submit this, now let's switch back. Let's return to our registered user controller. And instead of this, we're gonna die and dump all of the request data so we can see what we're working with. Alright, and we didn't get anything. Let's switch back. Um, yes, of course, I'm sorry, we forgot the name. Those little snippets didn't include it. So we'll say for your name.

Those little snippets didn't include it. So we'll say for your name. And this one has a name of email and then finally a name of password. We also might want to confirm the password and if that's the case, you could do something like this where you create another one and then you write password confirmation. But you know what? I could find it a little annoying

But you know what? I could find it a little annoying and actually from running a little business in my experiences, it's more important to repeat the email address because people get that wrong left and right. Anyways, let's try it one more time. Let's register and sure enough, all of the important data, uh, has been passed to our server. Okay, so now return to our controller

uh, has been passed to our server. Okay, so now return to our controller and let's just create the user. So let's outline the steps that need to be performed. And I will often do this, alright, what needs to happen here? Well, I need to validate the request. I need to create the user and the database. I need to log or sign them in. Log them in. And then finally I need to redirect, uh, back

I need to log or sign them in. Log them in. And then finally I need to redirect, uh, back to the home page. Cool, let's do it one step at a time. Alright, so validate the request. Once again, return to our learning. We can do this inline or we can generate a form request class. I'm just gonna do it inline here. So why don't we type the request?

I'm just gonna do it inline here. So why don't we type the request? We are asking Laravel to give us an instance of the request. Uh, and that's gonna be given to us through the Laravel container and we're gonna talk about that in the future. Anyways, for now, just consider it to be magic. It gives you what you need. Alright, so we're gonna say request, validate, and yeah, we're just gonna validate all of the parameters

Alright, so we're gonna say request, validate, and yeah, we're just gonna validate all of the parameters that were sent through here. Name, email, password, and let's see if AI can help us a little bit. Alright, the name is required string and yeah, often it's a good practice to set the maximum number of characters. This is the max for a, uh, simple, um, VAR card 2 55 field in your database.

This is the max for a, uh, simple, um, VAR card 2 55 field in your database. So if somebody tries to spam you with a 300 character name, that's gonna blow up on the database level. So why don't we catch it on the validation level instead? That's good practice. Um, yeah, very smart, good job. AI taking my job. So email is required, should be a string. Let's make sure it's a valid email address and also unique on the user's table. So that means there can't already be a user in our database

and also unique on the user's table. So that means there can't already be a user in our database that has the email address you provided. Okay, so that looks good, assuming that, uh, oh, let's do one more. We need one for password once again, great. Uh, so it's required. Uh, let's set a minimum number of characters of eight and if we wanted password confirmation, we could add confirmed, but I'm not doing that in this case.

and if we wanted password confirmation, we could add confirmed, but I'm not doing that in this case. Another option you can do by the way is reference the password validation rules and we can call default. So this, um, if we take a look real quick, you can see that we can register a default, um, list of password rules that can be reused across the application because you'll often have situations where you need to validate a password. So this consolidates it

to validate a password. So this consolidates it and sure enough we can see, um, what's being used here or a minimum of eight characters. Cool. So now this is redundant and we're in good shape here. So validation complete. And by the way, this is going to return your validated attributes, uh, if it passes. So now, yeah, if you want we can create the user

to return your validated attributes, uh, if it passes. So now, yeah, if you want we can create the user and we already know how to do this. We're using eloquent here. User create, and yeah, we can just reach for these, uh, fields like so, or if you want, you don't even need to use that. You can still access them directly off of the request. So you could say request, input, name, or even access it as a dynamic property as you see here.

So you could say request, input, name, or even access it as a dynamic property as you see here. And I will often take this approach. I feel like it looks, it looks just a little bit cleaner to my eyes. All right? Same thing for the email and then password's kind of an interesting case. So think about it. Could we do this? Well, first let's make a pint happy, but we could, but we shouldn't.

Well, first let's make a pint happy, but we could, but we shouldn't. So what's going on here? Well, we're, we are validating the request and let's imagine the user provides password here as their password. Um, well when we create the user now in our database, we're gonna have a user record where the password is literally set to the string password. And of course, if you've ever heard the phrase,

where the password is literally set to the string password. And of course, if you've ever heard the phrase, never store passwords in clear text in your db, well we are committing that crime right now. So instead we always want to hash our passwords and luckily Laravel has our back. We can do something like this. Let's use hash and I'm gonna pull in this one right here. Illuminate support facades hash, and we're gonna hash, uh,

Illuminate support facades hash, and we're gonna hash, uh, whatever password the user provides, which means the actual plain text version we are never tracking, we're never storing, we, we have no idea what their password is after this request. Alright, so that's it. We have validated the request. We have created a new user that will return to us, the created user. We can now log them in and you're gonna love this.

to us, the created user. We can now log them in and you're gonna love this. I can just say off log in the user, I told you Laravel is nice and readable. And then finally redirect them to whatever the, um, the homepage would be. So in our case, I think we're going to ideas as our homepage and that's fine. And this is a pretty bread and butter registration form. Uh, it's gonna do the trick justifying.

And this is a pretty bread and butter registration form. Uh, it's gonna do the trick justifying. Okay, so let's take a look in the browser, let's fill out the form again, register and we are redirected back and we don't really have any indication yet, but that's okay. We are in fact signed in. Let's have a look in the database and within my user table, sure enough,

Let's have a look in the database and within my user table, sure enough, we have our new John do account and this is paramount. Notice that the password is hashed. We have no clue what this password is. Very cool. Alright, so now if we're signed in, we probably shouldn't see a register button, right? That doesn't make sense. So let me show you some cool stuff we can do. Now if I return to my nav component,

you some cool stuff we can do. Now if I return to my nav component, it sounds like this link here should only be displayed on the condition that we are not signed in. So Laravel has some directives to assist us. I can use guest as well as off. And you can guess what these do, right? If you are authenticated, then proceed If you are a guest or if you're not signed in, then proceed. So if I were to wrap this with end guest, yeah,

or if you're not signed in, then proceed. So if I were to wrap this with end guest, yeah, behind the scenes, once again is just doing a little check, um, do we have an authenticated user? If so, then we should never see this because they're not a guest. Come back, refresh, and now it is hidden. Okay? Wow. Alright, so now why don't we do this? Uh, we'll combine these in just a minute, but we could also add an off directive that says, alright,

Uh, we'll combine these in just a minute, but we could also add an off directive that says, alright, well if you are signed in, then let's display a form to sign out. So I can say log out, give it a class, and this is gonna make a post request to, uh, the appropriate endpoint. And yeah, once again, you can do something like logout if you prefer, alright, come back, refresh.

you can do something like logout if you prefer, alright, come back, refresh. And now I have a logout button. And you know what, why don't we make this a ghost? All right, that looks good. Alright, so now if I click on this, well tries to make a VA post request, but we haven't registered that route, so we're gonna do that now. Alright, so again, we can be pretty creative here.

so we're gonna do that now. Alright, so again, we can be pretty creative here. So for example, do you want to follow kind of a restful convention or not? And there's no rule you have to do it every time. Sometimes it does make more sense to just step aside and create some simple, uh, endpoints and controllers. But yeah, if you want, you could do like logout controller, that would be fine. If you wanna call it sessions controller

controller, that would be fine. If you wanna call it sessions controller and stick to a restful uh, approach, then you might send a delete request to logout and this would hit a sessions controller and an action called Destroy. So think about it, A sessions controller would be responsible for creating a new user session by logging them in, but it can also destroy a a user session by logging them out.

by logging them in, but it can also destroy a a user session by logging them out. So that would be like the, the restful approach, but you don't have to do this if you don't want. Okay, so let's stick with this and let's create the controller, HB Artisan, make me a controller and this is gonna be off, uh, sessions controller and let's do resource and then we'll delete all of the methods

and let's do resource and then we'll delete all of the methods that are irrelevant to us. Alright, so now I can import this Open up sessions controller. And yeah, if you think about it, we would just have two methods. One, to create a new user session that shows the login form store, I guess would be appropriate. We're not gonna show a session, we're not gonna edit one,

store, I guess would be appropriate. We're not gonna show a session, we're not gonna edit one, we're not gonna update one, but we will destroy one. Okay? So now I can log out a user like this, I can say off, log out and then finally we can redirect to wherever home is. Once again, for now it's just that ideas endpoint. Alright, so let's see if this works. We currently have an endpoint that listens for a delete request.

We currently have an endpoint that listens for a delete request. And again, if we wanna really strictly follow this, maybe we would have an endpoint link sessions. And that's where I'm saying sometimes it just doesn't matter and it's better to follow, uh, a more readable approach if that works for you. Cool things to keep in mind, right? So now right here, this is going to submit a delete request to log out.

So now right here, this is going to submit a delete request to log out. All right, let's see if it works. Come back, let's log out and oh, whoops, what do we have here? Oh, it looks like it gave us something I didn't expect. All right, sorry about that. Come back one more time, log out and there we go. So it very quickly happened, but we logged the current user around, we redirected back to this page.

but we logged the current user around, we redirected back to this page. And now once again, I can see a register button. All right, so now very quickly I'm going to add a login form. So let's add another one here. This will be log in. Let's add a little space between, uh, each of our items here. Good. And then log in, maybe can have, I don't know, I'm not a developer.

Good. And then log in, maybe can have, I don't know, I'm not a developer. What do we wanna do here? Button secondary. What's the primary action in this case? Oh, this is looking pretty rough. I'm, I'm not a big fan of these colors, but it's, it's fine. Uh, for now it's a little fun. And then later we'll actually build something styled and very nice. Okay, so log in, it's gonna make a get request to log in.

styled and very nice. Okay, so log in, it's gonna make a get request to log in. We should create that, listen for a get request to log in and that's gonna create a new session, right? So we can say create sessions controller. Here's our create, we're gonna say return view off that login. Alright, let's create that view. And why don't we just steal some of our code from the register page.

And why don't we just steal some of our code from the register page. All right, so this will say login. And the login, you just need to give us an email address as well as a password. And then we'll say login. Alright, let's have a look in the browser, log in and there we go. Give us your email and your password. Alright, so now if we switch back, we're gonna make a post request to log in once again

Alright, so now if we switch back, we're gonna make a post request to log in once again or to sessions if we're being restful. Um, choose what you want there. So let's come back. We're kind of doing a hybrid approach here. Make a post request to log in and that will hit the store action. The store action once again is just going to validate the, um, request attributes. It will attempt to log the user in

um, request attributes. It will attempt to log the user in and then it will redirect. So validate, attempt a login and redirect. That's what we're doing here. So let's start by dying and dumping the request data for our sanity check. Here's our login page. We have all of the fields needed, so we give it a shot,

Here's our login page. We have all of the fields needed, so we give it a shot, Log in and there we go. We have email password. So check this out, this is kind of cool. I can now validate That your email address and once again is required is an email. And you'll often see this pipe syntax. So you'll see a bunch of rules separated by a pipe.

And you'll often see this pipe syntax. So you'll see a bunch of rules separated by a pipe. This is a very traditional old school way to do it. Still valid, but you might wanna do, uh, an email form instead. As you see here, email is string, uh, maximum two, you get the idea. Next this, we're not gonna do that. And then let's also, um, ensure that you provided the valid password.

And then let's also, um, ensure that you provided the valid password. And notice in this case, once again, if I didn't reach for that password defaults method, you end up in situations where you might duplicate, uh, some of your rules like this and that's not a good idea. Password default. All right, so now let's attempt to log the user in off attempt and we're gonna send through the validated attributes.

attempt and we're gonna send through the validated attributes. So yeah, in order to attempt to log the user in, we need an email address as well as their password. And that's it. So if the user could successfully sign in, then we're all set. And you'll see this is going to return a Boolean. Um, here we go. And that the Boolean of course indicates whether or not it could successfully sign the user in.

of course indicates whether or not it could successfully sign the user in. All right, so if off attempt, then we're all set and we can say return redirect and intended is something we haven't talked about yet, and it's actually very useful. So imagine a scenario where you attempt to visit a page that requires authentication. Well, we can set it up where that automatically redirects you to the login page,

Well, we can set it up where that automatically redirects you to the login page, and then once you successfully log in, we can send you to where you intended to go in the first place. So that's really cool and it saves you a step, but we're not gonna do that yet. We're just gonna return back to the ideas page. And by the way, later we're gonna learn about how to send through flash messages to provide just a little bit of feedback to the user.

through flash messages to provide just a little bit of feedback to the user. But we're gonna save that for now. Otherwise, if we reach this point, then of course the user provided invalid credentials. So what we can do is return back, and this is a good one to know, we're gonna return back to the previous form and we're gonna send through some error messages or validation error messages.

and we're gonna send through some error messages or validation error messages. So in this case, yeah, we'll use this. We're gonna say, all right, well, in the case we get to this point, the email or the password is wrong. So we can just attach it to email and say the provided credentials do not match our records. That way we don't indicate like there is no email or the, you don't need to know that. It's just what you provided to us is not working. All right?

or the, you don't need to know that. It's just what you provided to us is not working. All right? So we're not exposing anything, uh, too sensitive. Okay? Now the last thing you might want do, and this is kind of a good practice, is to regenerate the session token. And this just ensures every single time you sign in, we, we, uh, we recycle whatever token is, um, on your machine just to prevent any potential, um, hijacking, uh, situations where somebody tries to use a, a, an old token that, uh,

to prevent any potential, um, hijacking, uh, situations where somebody tries to use a, a, an old token that, uh, could still be relevant. So let's just always recycle or regenerate that when you log into your accounts. Alright? And that's it. So here's an example of logging in, validate, attempt to log them in, redirect upon success and redirect, uh, redirect back upon failure. And then you also have a register controller.

and redirect, uh, redirect back upon failure. And then you also have a register controller. And this is an example of registering a new user in your system. Once again, register, create the user, log them in. Redirect, okay, so we know that we have an existing user, right? So let's switch back. Let's try to use jish. What happens? Well, it does redirect back, but we provide no feedback. So let's not forget within our login form

Well, it does redirect back, but we provide no feedback. So let's not forget within our login form to display errors where needed. And luckily we already have that errors component. So if we take a look at this, we just need to give the name for the errors. So name is email. So let's log in and sure enough, we get provided credentials do not match our records.

and sure enough, we get provided credentials do not match our records. What if we fail? Uh, password validation, uh, we don't show anything. So let's do the same thing down here. All right, there we go. That looks good. Okay, so assuming we pass the validation then on the condition, um, that your credentials are incorrect, we provide some feedback to you.

that your credentials are incorrect, we provide some feedback to you. Okay? Let's do john@example.com. I believe his password is password and we're in, it's working. So here's our logout page. This is looking great. We can register a brand new user or we can log in like so. And then of course, we've also learned just as a recap

in like so. And then of course, we've also learned just as a recap to finish up this video, that on the navigation page, you can reach for directives like guest and auth. So in this case, by the way, if you want, you can merge these by saying, all right else, if you're not authenticated, then you're a guest. In which case we should display these links here. And that allows you to simplify it just a little bit, log out, and it's still going to work the way it did before.

And that allows you to simplify it just a little bit, log out, and it's still going to work the way it did before. So now this is the next order of business. If I switch back up until this point, we've been creating ideas that are just relevant to everyone, they're global ideas. But now that we have actual accounts, it would make sense to see a list of my ideas and my ideas only. So let's work on that in the very next episode. I hope you're excited.

So let's work on that in the very next episode. I hope you're excited.