Nested Middleware - make the inside Middleware an exception

@MichalOravec I really read the docs but sometimes miss stuff🤪

But, will it work in such case of Middleware with parameters (I will test it now but still wanted to ask you):

Route::middleware(['permission:permission_x'])->group(function () {
    // many routes
    Route::middleware(['permission:permission_x,permission_y'])->group(function () {
       // some specific route
    })->withoutMiddleware(['permission:permission_x']);
});

Because it's not that I want to exclude the Middleware entirely, just change the parameters. I don't want it to even ignore itself

@Ligonsker I've never used it.

@MichalOravec Will try now and update

@Sinnbeck Yep, this is what's I'm going to do because anyway @michaloravec this is Laravel 6 (I know it's not supported but it takes time to approve the updates where I work), and it tells me that withoutMiddleware() does not exist.

@sinnbeck if I was working on Laravel 9, would the withoutMiddleware still work? Even though it's from outside in?

@Ligonsker I believe that was added in laravel 7

@Sinnbeck Would that work? Even though normally it goes outside in? And in this specific case, it's the same Middleware (different parameters):

Route::middleware(['permission:permission_x'])->group(function () {
    // many routes
    Route::middleware(['permission:permission_x,permission_y'])->group(function () {
       // some specific route
    })->withoutMiddleware(['permission:permission_x']);
});

@Ligonsker Why would you nest it in the outer middleware in the first place? I havent tested so myself, as I would refrain from using this pattern, but I would assume so (no promises)

@Sinnbeck Because in the real file there are many routes that use permission_x, and only a few use also permission_y (Updated the previous comment, added both):

Route::middleware(['permission:permission_x'])->group(function () {

    // many routes

    Route::middleware(['permission:permission_x,permission_y'])->group(function () {
           // some specific route
    })->withoutMiddleware(['permission:permission_x']);
});

And since there is only a small group of routes that needs both, I can wrap everything with the permission that is used the most with exception of a few, so not to repeat many times. (Because permission group x does not necessarily include the same users in permission group y)

@Ligonsker Perhaps you need to look a bit broader than that.

Ideally permission would control the ability to do one thing, whereas a user might have a role that conveys a number of permissions.

So nesting permissions never becomes a problem.

@Snapey you are correct, in fact I was wrong in my example, in reality it's more like "permission groups". But in my case there is still this case where sometimes 2 separate roles, for example 2 types of managers have similar permissions, but not identical, but for that specific route I want both of the managers to be able to use it.

I know it is still likely due to the design and broader problem - what could I do to make it better? Or in this case it's alright

@Ligonsker I cannot think of a reason why 1 action can be done with two different permissions? I would assume there is just one permission and that both manager roles has this

@Sinnbeck You are right, then I should probably change the design as well. Currently how it works is that there is a table of permission_groups, which is simply column of user_id and the permission_name:

user_id | permission_name

so it implicitly creates "permission groups", but it's not exactly. So a permission group is all the users that are assigned the same permission_name (which also turns out to be the group name).

Should I change this design? Maybe add another table? And create a relationship between the role and the permission?

So I will have this table:

permission_name | permission_group

and then the user will have relationship between the actual group:

user_id | permission_group

Would you do it like that? Or something else?

@Ligonsker can I recommend you have a look at this. It just works and my guess is that a lot of the people in here use it (I use it on multiple projects) https://spatie.be/docs/laravel-permission/v5/introduction

@Sinnbeck I used spatie in a previous project (not in the current place I Work), but if you remember, installing a new package here . . .😅😅😅

But looks like Spatie also creates these tables: permissions and groups, unlike my current situation where it's only list of users-to-permission relationship

@Ligonsker ah yes I forgot. But you could perhaps just copy the files over? It's a few traits, models and migrations and such. Just change the namespace

@Sinnbeck I could try, but that also means to completely remove the permission check in the web.php file right? completely change the design