Alright, hey everybody. So in the last episode, you had your first introduction to session handling, right? Sessions 101. But now, let's kick things up a notch and figure out an actual practical use case for sessions within an application. Alright, let's get going. If I open my routes file, yeah, of course we will build a form to register a new User. So let's start with the routes, and we'll keep it very simple. This will go into a controller's directory, and why don't we call it, I don't know, RegistrationController::create.

This will go into a controller's directory, and why don't we call it, I don't know, registration/create. How about that? Alright, let's go in here. Create a new directory called registration, and then our first php file for create. Alright, so this will load a view, and just like before, it'll go in a registration directory, and we'll name it the same thing. Alright, let's create the view. views. Let's add our directory, and then create.

Views. Let's add our directory, and then create. And I'm sorry, I forgot, we gave these a .view extension. Alright, and then just to save myself a little time, why don't we grab some of this, and then we can replace it all with a register here, something like that. Alright, let's have a look in the browser. Alright, so here's the homepage, and yeah, I don't yet have a link to register. We will probably put it right up here. But yeah, for now, if I manually visit that URI, alright, it works. Now, of course, in this case, I get a warning because we haven't yet provided a heading.

we have an email address and a password. So the next thing I'd like to do is update the form itself. And you can see, what do they give us by default? It's going to make a POST request, but the action is a hash symbol. So why don't we have it POST to that exact same endpoint? And then we will have a look at each field. All right, so yeah, in our database, we're going to call this column email. So why don't we update this like so. All right, password looks good. And then the only thing I don't see is some validation errors.

All right, password looks good. And then the only thing I don't see is some validation errors. So I think we did this, hmm, let's go into notes/create. And yeah, a number of episodes ago, didn't we have something? Yeah, right there. All right, let's switch back. And I don't know if this is right, but we could try putting it there to start. And we could say, if there's any errors for the email, show it here. This may not be right for formatting with this component, but it's good enough at least to illustrate the approach.

This may not be right for formatting with this component, but it's good enough at least to illustrate the approach. And we'll do the same thing if there happens to be any errors for the password. All right, come back, give it a refresh. And this looks good to me. Okay, so now if I were to submit this form, of course, we're going to get a 404 because it tried to submit a POST request to /register, but we haven't yet created a route for that. So that would be the next step. Go back to your routes file.

So that would be the next step. Go back to your routes file. I will duplicate this line and now listen for a POST request. And that will hit a store action or a StoreController. Okay, come on up and let's duplicate this store. And now I'm just going to say here to show that it works, register the User. Okay, come back, give it another try, hit register. And now we have hit that endpoint. Okay, so of course, at this point, within the $_POST super global, we should have access to the email address and the password that the User provided.

Okay, so of course, at this point, within the $_POST super global, we should have access to the email address and the password that the user provided. So let's give that a shot. I will type password here. We register and we see it looks like K1 has some kind of remember input that I will get rid of. But then we have our email address and our password. Okay, so that means the provided email will be $_POST['email']. The provided password would be $_POST['password']. Okay, so now, yeah, at this point, you're going to follow the exact same steps that we've used for every other form, just with a slight tweak.

Okay, so now, yeah, at this point, you're going to follow the exact same steps that we've used for every other form, just with a slight tweak. So think about it. We would want to validate the form inputs. We would want to, but then at this point, after we validate, think about it. You'd want to check. What if I try to register jeffrey@laracasts.com, but there's already an account? For jeffrey@laracasts.com. We need to check for that. So check if the account already exists.

But I find even after having done this for years and years, it's useful just to get your mind in order of what do I need to do? You know, if you're trying to plot out your day, you might take out a notepad and say, I got to do this and this and this. The same is going to be true for the programs you write. And then when you're done, you can just erase each comment as you complete it. All right. So in this case, validate the inputs. Well, I could say validator. And you'll remember we have two methods, one to validate a string and one to validate

Well, I could say validator. And you'll remember we have two methods, one to validate a string and one to validate an email. So why don't we start with the email? Validate the email. And if it is not valid, then let's append to an errors array like we've done before. So we might say errors email. Please provide an email address. And not just an email address, but a valid email address. All right.

And not just an email address, but a valid email address. All right. Next, why don't we validate the password? Let's do a string for the password. And you'll remember when we created this a number of episodes ago, we can accept the number of characters that we want to check for. So why don't we say a password has to be at least seven characters, but no more than 255 characters. 255 is just a common maximum character count for your database of our varchar or variable character columns.

255 is just a common maximum character count for your database of our cards or variable character columns. OK. So the next step would be, well, if the errors array is not empty, then we have a problem. So again, you will eventually learn about a process where if validation fails, you would actually redirect. But at this point, we're still going to return a view. So let's return our registration/create view. And then I'm going to pass through the corresponding errors. All right.

And at this point, if we get beyond this clump of code that later I'll show you how to clean up and organize better, then we can move on to this section. Check if the account already exists. So what we might want to do is grab or resolve our database class that we created. And then I could say DB query(). And let's say select * from the users table where the email address equals the one that was submitted through the registration form. And if there is, well, think about it. That means, hey, we already have an account for that email address. So let's run that query.

That means, hey, we already have an account for that email address. So let's run that query. We'll send through the $email and get the result. So we'll save that $result and then find a corresponding record and then dd. And we'll have a talk about this. All right. So before we run this in the browser, let's switch over to TablePlus. And we'll have a look at that users table from a number of episodes ago. And yeah, right now it just has a name and an email. Why don't we tweak this a little bit?

And yeah, right now it just has a name and an email. Why don't we tweak this a little bit? Let's say instead of name, we're going to have a password that cannot be null. OK. So now, again, it's super simple. In real life, you'll have many more columns. But at the moment, our users table contains an email address and a password. And that's it. And let's then populate it with something like joe@example.com and then a password that's stored in clear text, which is a really big no-no.

And let's then populate it with something like joe@example.com and then a password that's stored in clear text, which is a really big no-no. And we're going to fix that in a little bit, but not quite yet. OK. And yeah, we'll give it a shot. All right. So back to the register page. We will register an email address that already exists in the database. And we should die. And there we go.

However, if I try to register an account that does not exist within that table, you'll see that it returns false. So yeah, at this point, this is where we have our branch. We could say $user. And yeah, right here, you could say, well, if we have a User in the database, then someone with that email already exists and has an account, right? That's basically what that means. So we said, on that condition, redirect to the login page. So we could say header("Location: login"). But you know what?

And this is where we can actually start working with sessions. So let's see. We start with a new query. Insert into the users table. And we want to give it an email address and a password. And the values, of course, will be email and password. And then I will pass those bindings through. So again, for the moment, I'm going to pass this password in clear text. But yeah, in the near future, I will teach you how to hash the password and then compare it when we build the login form.

But yeah, in the near future, I will teach you how to hash the password and then compare it when we build the login form. And that's why I'm holding off. All right, so we have created the account. At this point, we sort of want to mark that the User has logged in. So I think that would be a good use for sessions. I could say session. And yeah, you could do something like this, loggedIn if you want. Or maybe you just add maybe a key like user. And you make that equal to whatever you want.

Or maybe you just add maybe a key like user. And you make that equal to whatever you want. How about an array itself, where the email address is the user's email? Or maybe you add multiple things. Like maybe you add the user, but you also have some helpers like this that you set to true, whatever you want to do here. OK, so there's more to do here. Ideally, there are some good practices about how you create new sessions, how you log in, when you regenerate the session. But we'll get to all of that in the next episode or two.

how you log in, when you regenerate the session. But we'll get to all of that in the next episode or two. The final step for now is to redirect. And often, this is like to the User's private dashboard or their settings area. For now, once again, we will redirect to the home page. And then we can exit or die. And we can do the same thing up there as well. That's always a good practice. After you redirect, kill the script, basically. Exit because you want to ensure there's no scenario

After you redirect, kill the script, basically. Exit because you want to ensure there's no scenario where the script continues being executed after the header. All right. So a lot of stuff here. And again, I promise you there are ways to clean this up and ways to simplify things. But it's good to do it this way to have a general idea of the flow. And you'll find that this happens over and over, where you submit a form and you need to validate it a little bit. You may need to run a database query.

and you need to validate it a little bit. You may need to run a database query. You may need to respond dependent upon the state of that database. You might want to append things to the session or to the cache. This is all really common stuff that you will write over and over. OK. So the only remaining step is to ensure that this works. So I think we're going to make use of this. All right. So let's say when the User goes to the IndexController, that will hit this view.

All right. So let's say when the UserController goes to the index method, that will hit this view. So let's scroll down into the index view. And yeah, maybe we can go into the navigation area. And let's see. What I want to do, if I switch back, is find this section here with this guy. So it looks like they're using unsplash.com. There it is. So let's see. If I get rid of that, is that the one?

So let's see. If I get rid of that, is that the one? Yeah. OK. So why don't we do this? Why don't... We'll still use that avatar to assume that you're logged in. But I might say, well, if session user... And remember, we can't always assume that anything is in the session. So we could check for if isSet or assume that it's false.

And remember, we can't always assume that anything is in the session. So we could check for if isSet or assume that it's false. We could do something like that. If they're signed in, then show that image. Otherwise, maybe we have a link to register or log in, right? So let's start with a registration link. Register. And that will go to /register. And yeah, this is how we can handle that sort of flow. All right.