Buy

This Chapter isn't quite ready yet

Rest assured, the gnomes are hard at work on completing this video

Coming soon...

So far, everything that we've been talking about is authentication, it's how your user logs in, but at this point our users can log in, we can check their passwords, were loading user from the database or even checking the CSRF protection. We have a working authentication system, so we're going to start turning too, so I wanna start talking about these second part of security authorization. This is the part that decides whether or not you have access to something. This is where you make certain where you, for example, require the user to log in before they see some page. There are multiple ways to do authorization depending on how much control you want to have. I far the easiest one is right at the bottom of your security. That yammel file, it's called access control. On comment, the first access control, this is pretty cool. The path here is a regular expression, so this access control says that any you were out that starts with slash admin should require a role called role admin. We'll talk about roles and the second. Now, if you go to your terminal and run bin Console diva router, you might remember that we do have a couple of urls that are under slash admin slash admin slash comment. So let's see what happens when we try to access this page

and access denied. We get kicked out. So let's talk about how roles work in symphony. It's simple and it's beautiful. If you click down on the web debug toolbar, if you click your user icon, you'll see that we're logged in a space bar one, an example of the calm and we have one role role underscore user. The idea is that you give your users a certain a certain set of roles and then you run around your site protecting different urls with different roles. Since our user doesn't have admin, we are denied access. Now why does our user have role underscore user? The reason for that is inside of our user class, remember when we ran make user, one of the methods that it generated for us was good roles. And look at this carefully. It reads some enrolls property, which is an array property stored in the database. And right now this property is empty for every user in the system, but they get roles. Method that was generated has a little extra logic here that guarantees that every user at least has this one roll. Roll underscore user. This is really nice because we now know that if you are logged in, you definitely have this one role. Also, you want to make sure that you get roles always returns at least one role or else weird stuff happens and you don't look completely logged in.

So for example, to prove this is working, if we changed the role admin tool user in access control and reloaded and went back to that admin page, yes it would work. Let's change that back to role admin.

As you can see the examples down here, you're allowed to have as many access controls as you want each having their own regular expression for the path. The one important thing is that access controls work like routes. Symphony checks them one by one from top to bottom, and as soon as it finds one access control that matches, it uses that access control and stops. So you can only have a maximum of one access control that ever matches one url. Just something to keep in mind as you're setting those up. The other thing is that if you refresh, the other thing I wanna mention is that when refresh to see this big access denied four, oh, three forbidden page. We're not going to go through it in this tutorial, but there's a very easy, if you google for symphony error pages, there's a really easy way to customize how this error page looks in the production environment. So you can make your four three page look a certain way and you can make your four page where it will look a certain way. This big exception exception pages, obviously only something that you're gonna. See while you're developing.

Now I want to show you one more thing before we start talking more about authorization. Log Out. I have a question now that we're logged out. What do you think will happen when we go to slash admin slash comment? Are we going to get an access denied after all? We were anonymous, so we of course don't have the role admin role. Well, let's find out. No, we go to the login page. This is awesome because of course if you think about it, that's exactly the behavior you want. If I'm not logged in yet and I try to access a page that requires me to be logged in, it should send me to the login page. The logic to do this, the laundry to do this is actually handled by our abstract form login authenticator class that has a method in it that decides what to do when an anonymous user tries to access something. It's called an entry point. It's something we're gonna talk about later when we talk about API authentication anyways, it does exactly what we want. It redirects to the login page, but now check this out. Let's log back in and space bar one. An example of that. Com password engage in. Where do you think I should be sent after I log in? Well, let's find out. Hit Enter and we're sent it to the login page. Perfect, right? No, not perfect. I originally tried to go to slash admin slash comments, so after I log in to have a good user experience, we should be redirected back to that. You were up.

The reason that were sent to the home page is because of our code in login form authenticator on authentication. Success always sends the user to the homepage. How could it be? The question is how could we update this method to send the. You were all back to the previous. You were out, they were trying to access, well, here's the really cool thing. I'm going to go back, log out again, and then go back to slash admin slash comment. Whenever you try to access a url as an anonymous user, before it redirect to the login page, it saves that url slash admin slash comments into the session in a very special key. So if we can read that value from the session inside of our method, we can very easily redirect the user back there and to make life even better. Symphony has a shortcuts. Do this. At the top of your authenticator, we're going to use a trait called say, use target path trait. Target Path is the name that we gave to the path that the user wants to go do after logging in. Then down here in, down in on authentication access, say if target path

equals this Arrow get target path. That's a method from that, from that trait, and pat this need to pass this session. So request Arrow get session. We also need to pass this the provider key, which is actually an argument in this method to provide a gates actually your firewall name not too important right here. Uh, we can just pass it on. So the, if statement might look a little confusing to you, I'm actually assigning a variable then immediately checking to see if that variable is, is empty or not. So if it's not empty, if there is something stored in that target path session area, then we're just going to say return new redirect response. And instead of generating a url, we're just gonna set that target path. That's it. If there was nothing set, which can happen, if the user directly went to the login page, then we'll fall back to the homepage. All right, check this out. We should be able to immediately log in with password engage and we've got it. Yeah, it's access denied because we don't have access, but the url took us back to slash admin slash comment. That is a killer login flow.

Leave a comment!