Add Register Navigation Link 0:00The final piece of the puzzle is to actually log the user in. So let's take care of that. But first, we do need some kind of link to visit the registration page. Notice this says home page, but that's redundant with the logo here. They both go to the home page. So why don't we add it there? That's in our layout file, and here's that link to the home page. So I will change that to register, and then of course the link is slash register. Okay, so now I have an easy way to sign up. But before we submit this, yeah, let's go back to that controller, register controller. Log In After Registration 0:29Okay, so now I have an easy way to sign up. But before we submit this, yeah, let's go back to that controller, register controller. In here, we validate the request, we create the user, we redirect with a flash message. But again, we never actually log the user in. All we did was create the user, but they're not yet signed in. We can do it pretty easily using this auth helper or the auth facade that you can pull in here. They're both functionally identical. Auth login the given user. And what user? Well, the user we just created here.And what user? Well, the user we just created here. So let's save that. And that's the final piece of the puzzle. At this point, when we are redirected to the home page, the user will be signed in. Let's give it a shot. I'm going to sign in, we'll do myself this time, Jeffrey Way. Jeffrey at layercast.com, password. All right, we get our flash message. I should have an account in the database.All right, we get our flash message. I should have an account in the database. There it is. If I switch back, the flash message should disappear. Everything's looking good. And yet there still isn't feedback that I'm signed in other than that flash message. And in fact, I can even go back to the registration page, which doesn't make sense because I already have an account and I'm already signed in. All right, we have a few things to tackle in this video, so let's get going. The first thing I'm going to do is in my routes file, I'm going to say, Protect Routes with Middleware 1:51All right, we have a few things to tackle in this video, so let's get going. The first thing I'm going to do is in my routes file, I'm going to say, these endpoints only make sense if you aren't signed in. If you are signed in, then why are you registering, right? So for both of these routes, I'm going to add a middleware, which is a new concept, called guest. Now, middleware can be a little confusing. It's slightly more higher level. Just think of it as a piece of logic that will run whenever a new request comes in. So as a new request comes in and it works its way to the core of your application, you have the opportunity to inspect that request and perform certain pieces of logic or even redirect the user elsewhere.So as a new request comes in and it works its way to the core of your application, you have the opportunity to inspect that request and perform certain pieces of logic or even redirect the user elsewhere. So in this case, Laravel has a middleware called guest. And as you could probably imagine, this is going to say only a guest can access this page. If you're signed in, it doesn't make sense for you to visit a register page. So we should redirect you somewhere else. And the same thing is going to be true for this other route, middleware guest. Now, you can find all of your middleware within the app HTTP middleware directory. And again, this is slightly higher level. It might be a bit more confusing.And again, this is slightly higher level. It might be a bit more confusing. And you can review your kernel class for all of the references here. So we're not going to focus on this too much, but just know for now, your middleware are divided into two types. Global middleware that run automatically as part of an incoming request. So notice, if you're building a website, these middleware will run without you even knowing about it. But then we also have route-specific middleware. These are pieces of logic that can optionally be added to a particular route. So notice in our case, we used guest. And in each of these cases, we have a key that corresponds to a class.So notice in our case, we used guest. And in each of these cases, we have a key that corresponds to a class. So if I want to only allow guests, notice this logic. Again, it can be a little confusing. Just look real quick. Auth, we're going to check if the user is signed in. And if they are, they can't visit this page. So let's redirect them to the homepage instead. Now, alternatively, there's the inverse, auth. This would say, if you're a guest, you're not allowed to access this page.Now, alternatively, there's the inverse, auth. This would say, if you're a guest, you're not allowed to access this page. So maybe the members-only dashboard would be protected by the auth middleware. If you're not signed in, you're not allowed to access this page. So add the auth middleware. Okay, so let's give that a shot. If I refresh, notice, well, it's trying to redirect me to an endpoint that doesn't exist, but the middleware did, in fact, work. So you'll remember, if we go back to guest, it's trying to redirect us to route-service-provider-home.So you'll remember, if we go back to guest, it's trying to redirect us to route-service-provider-home. Let's go into our route-service-provider, which is in your app providers directory, and you'll see it there. And yeah, notice you have this const that refers to a path to the homepage. So let's just change it to that. Redirect a user after login to this page. Okay, so now I will go back to register, and there we go. Because I'm already signed in, it redirects me to the homepage. But they can still click on this, and that would be confusing. Conditionally Render Nav Links 4:58Because I'm already signed in, it redirects me to the homepage. But they can still click on this, and that would be confusing. So why don't we conditionally show that link only if it's appropriate? Back to my layout file, and then right here, I can say, well, if you're a guest, and I can use this guest directive. Only if you're a guest should we render a register link. Refresh, and I no longer see it. But if I open this in an incognito window, I do see it, because in this browser, we're not signed in, of course. Okay, so this guest directive is just a helperI do see it, because in this browser, we're not signed in, of course. Okay, so this guest directive is just a helper that would translate to something like if auth check. Check to see if the current user is signed in. And if they are, or rather, if they're not, or we could even use the unless directive. So there's so many different ways you can write the exact piece of logic. And that's what's fun about programming. You can build up your own particular style for how you want to approach these things.You can build up your own particular style for how you want to approach these things. Refresh, and I get the same thing. But yeah, in most cases, stick with the directives. It's a little more readable. So I'm going to backtrack to guest. Now, another option would be to use the inverse, auth. If the user is signed in, then render this. And of course, in this case, it would make sense, but just to show you that because we're signed in, we do render the contents.And of course, in this case, it would make sense, but just to show you that because we're signed in, we do render the contents. So maybe we could say, if you're signed in, show one anchor tag. If you're a guest, show a different anchor tag. And you know what, maybe this isn't even an anchor tag. I don't know, maybe it's a span that will say, welcome back. Just to give you some ideas for how you could structure your pages based upon whether the user is currently signed in. Or we could say welcome, and then the person's name, auth user name. So notice how useful this auth helper is.Or we could say welcome, and then the person's name, auth user name. So notice how useful this auth helper is. We've so far said auth log in a user, or auth check if a user is signed in. Or get the user object of the person who is signed in. So if you're not signed in, auth user would return null. So you just want to be careful. Only use this auth user name if you're positive that the user is signed in, which is what this check here is for. But yeah, now we're going to say, welcome Jeffrey Way. It works. Implement Logout Flow 7:23But yeah, now we're going to say, welcome Jeffrey Way. It works. But on that note, we also need a way to log the user out. And that should probably be somewhere up here in the navigation bar. So why don't we say, hmm, if you're signed in, let's add a form that will submit a POST request to log out. And then we'll have a little button here, type submit, log out. And let's see what that looks like. It's not going to be pretty, but we do have our log out link there. And yeah, it didn't look very good.It's not going to be pretty, but we do have our log out link there. And yeah, it didn't look very good. But why don't we, on the wrapping div, let's just make it a display of flex. And that will put it in a line. We could even align these to the center. And in fact, actually, let's do this. I don't want to spend too much time on this. But to get us going, yeah, and that's already starting to look a little better.But to get us going, yeah, and that's already starting to look a little better. And in fact, we could even set class text extra small, font semi-bold, maybe even text blue. And then let's give it some margin left. And it's not great, but it's enough to get the job done. So when I click on this, it's going to submit a POST request to slash log out. And don't forget, I've included that CSRF token. So if we run it, yeah, we get a 404 because we don't have a corresponding endpoint.So if we run it, yeah, we get a 404 because we don't have a corresponding endpoint. So that's our next step. Right here, route POST to log out. And why don't we create a special controller for that? You could do something like a single action logout controller. Or sometimes I'll use something generic, like sessions controller. This controls the sessions for our site. And in this case, I specifically want to destroy the session. All right, let's create our controller, phpArtisan,And in this case, I specifically want to destroy the session. All right, let's create our controller, phpArtisan, makeController, sessionsController. All right, and then as always, I import that at the top. All right. So now if I destroy, we'll start by saying, log the user out, just to prove that we are hitting this endpoint. Come back, refresh, log out, and there we go. So it's really easy to log a user out. Auth, and you've learned already, log in, log in a user.So it's really easy to log a user out. Auth, and you've learned already, log in, log in a user. Check to see if a user is logged in. We have one called guest. Do we have a guest at the moment? But in our case, we want to log out the current user. So after we log out, let's redirect back to the home page and add a flash message, with success, goodbye. And I'm not using the request here. And that's what we get. Add Login Link Placeholder 10:06And I'm not using the request here. And that's what we get. I click log out, we see our flash message, and notice now we see a link to register. But we probably need a link to log in. You can register or log in. Let's do that now. In my guest section, let's duplicate this. And we'll say log in, and then it'll take us to the endpoint login. All right, let's see how that looks.And we'll say log in, and then it'll take us to the endpoint login. All right, let's see how that looks. Refresh, and maybe a little bit more. Yeah, again, good enough. So we can register, or we can log in. But right now, that endpoint doesn't exist. So we'll knock that out in the next episode.
