Our role-based system is what I would call a hybrid system, because we have some things that are soft-coded, meaning that they are in the database, like our roles and the assignment of roles. All of that is soft-coded. But then we have some things that are hard-coded, such as the actual authorization logic. All of that is hard-coded in our application's code. And I like hybrid applications, because you can go one way. You can hard-code everything,

And I like hybrid applications, because you can go one way. You can hard-code everything, which means that any change that you need to make has to be done directly inside of the code. But then you can go completely the other direction and completely soft-code everything, which is really cool. It's really flexible. It's also really complicated, because then everything involving authorization is in the database,

It's also really complicated, because then everything involving authorization is in the database, not just the roles and the assignment of roles, but you have to think about routes. You have to think about middleware. You have to think about your authorization logic. All of that is in the database. I'm going on. I need to shut up. The issue, though, when you have soft-coded roles or soft-coded permissions is that, well, they can change.

The issue, though, when you have soft-coded roles or soft-coded permissions is that, well, they can change. Like, for example, behind the scenes, I've implemented this role management system so that we can create new roles, and more importantly, we can edit roles. So if I wanted to edit the admin role, you know, I could do that. And then I've broken the application. The reason being because our roles and the assignment of roles

And then I've broken the application. The reason being because our roles and the assignment of roles are defined inside of the database, but the actual authorization rules are hard-coded. So this could be a problem. Now, I get it. The solution to something like this is, well, just don't do that, of course. But if there's one thing that I've learned over the many years of writing software,

But if there's one thing that I've learned over the many years of writing software, it's that I need to prepare for things that I know will probably change. This is something that I will probably want to change at some point in time. So I might as well go ahead and implement the ability to modify our roles. But of course, that's going to be a problem unless if we plan for it.

But of course, that's going to be a problem unless if we plan for it. And what we can do then is, for our roles table, we could still have our name. The name is a nice human-readable bit of text that we should have. But then we could have something that is not going to change, something that is unique for each individual role. And it's something that we could then use to check if a user is in a given role.

And it's something that we could then use to check if a User is in a given role. And so I'm just going to call that authCode. So our role table is going to change. We'll have an authCode, which is really what we would use inside of our application code to check if a User is in a given role. And then we would have the name, something that we could display to the User.

And then we would have the name, something that we could display to the User that's easy to understand. So this means that we will need to go to our database seeder and we need to change our roles. What we have as our names right now are going to become the auth code. But then we also need the actual names. So the name for our admin role could be the system administrator.

So the name for our admin role could be the system administrator. Then when it comes to the author, we could say that that is the Article author. And for the editor, we will essentially say the same thing except that it is the Article editor. Everything else will be the same, but we do need to go ahead and make those changes to the database.

but we do need to go ahead and make those changes to the database. So I'm going to wipe out the database. Then we will migrate the database with our updated roles table. Then we will seed the database. Everything should work because we didn't really change much there. But then we need to change practically everything involving

But then we need to change practically everything involving where we check for our roles. But that's actually going to be very simple because we do this in two different places. The first is going to be the loadRoles middleware because we load our roles here, but now we want to plug the auth code instead of the name. That's a very simple change and we're done there.

instead of the name. That's a very simple change and we're done there. But then we need to go to the User model because this is where we have the hasRole and the hasAnyRole methods. But this is where we get to see the beauty of this particular implementation because all of our authorization rules rely upon these two methods. It doesn't matter if it's our role checking middleware,

rely upon these two methods. It doesn't matter if it's our role checking middleware, if it's our role directive, if it is our article policy. Every single place that we have checked if a user is in a given role, we have done so by using these two methods. So all we need to do here is, well, we don't have to do anything for the context stuff. We just need to change the column.

well, we don't have to do anything for the context stuff. We just need to change the column. If we hit the database, we don't want to check the name, we want to check the auth code and that's it. And with that simple change, our application is going to work exactly like it did before, except that now we have roles that we can edit. So I'm not going to go into everything,

except that now we have roles that we can edit. So I'm not going to go into everything, but we signed in as admin. We can see that we can view the users, we can go to the edit page, although, yeah, we do need to modify the edit users. So let's go ahead and do that. Let's open up the edit view for our users. And we did everything based upon the role name here. So if we have the role and auth code,

And we did everything based upon the role name here. So if we have the role and auth code, then we output the name, that alone should fix that. And sure enough, it does. So the author is there. Let's be sure though, let's go to the author editor. And sure enough, those roles are selected. We can view the articles.

And sure enough, those roles are selected. We can view the articles. Everything is working as it should. So then the only other thing that I want to do is take that new auth code into account here. Now, of course, I implemented this role management system behind the scenes, and I didn't prepare it for this particular theme because, well, that's what this episode is for. So we are going to add the auth code field here.

because, well, that's what this episode is for. So we are going to add the authCode field here whenever we want to create a Role. That's not correct, that shouldn't say articles. So let's open up the create view for our roles. Let's change that so that that says roles at the top. And let's do this. Let's just copy what we have for the name here. And we're going to paste it in for the authCode. But of course, we need to make changes

And we're going to paste it in for the authCode. But of course, we need to make changes so that instead of name, we are using the authCode. The label here will be simply auth code. And I don't think, well, yeah, we have some other things we need to do. Let's get rid of this autocomplete because that was for the article. And the autofocus will autofocus the authCode.

because that was for the article. And the autofocus will autofocus the auth code. So that should fix that. And so let's take a look at the store method. So whenever we want to create a role, we create that and everything. But we do need to check the validation rules because now that we have this auth code, we need to validate it. And there's a few things that we need to validate.

we need to validate it. And there's a few things that we need to validate. First of all, it needs to be required and it also needs to be unique based upon the roles table and the auth_code column. And I think that that should be enough. But I guess we can include the other things that we did with the name as well because we do want it to be a string. We do want some kind of max set.

because we do want it to be a string. We do want some kind of max set. So that should be fine. The only other thing that I need to check though is the fillable array. So I put name there. Now we need auth code. And yeah, that should work. So now we should be able to easily create a role. So we're going to be implementing a new feature.

So now we should be able to easily create a Role. So we're going to be implementing a new feature. So we'll have the auth code set to featureUser. And then the name, we'll just have featureUser for the lack of creativity on my part. We'll save this. And sure enough, we have the featureUser. But whenever we try to edit this, we just see the name. And ideally, yes, that is what we want.

we just see the name. And ideally, yes, that is what we want. We don't want to be able to edit the auth code. But at the same time, I would like to be able to see what that auth code is. So let's add it to the form, but we will make it read only. So let's copy what we have inside of our create view. And let's open up the edit view for our roles because we're just going to paste that in.

And let's open up the edit view for our roles because we're just going to paste that in. And since we aren't going to be changing the auth code, we'll get rid of the error message. The value, well, I guess we could leave it as the old auth code, but really, we just need the roles auth code because that's never going to change. And then finally, this isn't required. It's not autofocus because it is going to be readOnly.

And then finally, this isn't required. It's not autofocus because it is going to be read only. But of course, we need to take that into account whenever we edit the role. So for the update method, instead of updating all, I'm just going to do this. We will be explicit here that we are going to update the name based upon the name from the request. That way, if the auth code is submitted, we completely ignore it and we don't worry about it.

That way, if the auth code is submitted, we completely ignore it and we don't worry about it. So now instead of the edit page, we can see the auth code. We can't make any changes to it, but we can change the name of the role. But I think I would like to have the auth code listed here as well. So let's open up the index view. Let's first of all, change the articles so that it says roles.

Let's first of all, change the articles so that it says roles. And then for our table, we will have the role name followed by the auth code just so that we can see that in the list. That way, we don't have to go to the individual pages to view the auth code for those roles. So that's after the name, we have the auth code. And now we see the auth code with the roles. We can edit our roles and see the auth code.

And now we see the auth code with the roles. We can edit our roles and see the auth code. We can't change it, which is exactly the behavior that we want. Now, this isn't an issue specifically with role-based systems. We ran into this particular issue because we have a hybrid system. We have some soft-coded things and we use those soft-coded things hard-codedly.

We have some soft-coded things and we use those soft-coded things hard-codedly inside of our code. Is that even a word? I don't know. But that is the issue that we faced. And it's common, especially as you are building authorization into your application. The important thing is to plan for it, which we kind of did without really planning for it. Since all of our authorization hinged upon

which we kind of did without really planning for it. Since all of our authorization hinged upon the two methods in our User model, the hasRole and hasAnyRole, it made it easy for us to change and update our application.