RBAC permissions authentication, user rights are stored in the session?

RBAC permission authentication.
Once a user logs on, it is not possible to query the database once per request.
1. Do you take all of the interface addresses that he has access to and then save them to the session?
2. In Laravel, some interfaces require authentication, some interfaces are open, I now route is so, there is no more elegant way to implement?

Route::group(['prefix' => 'api/v1'],function(){    Route::post('login',"AccountController@Login");    Route::group(['middleware'=>'auth'],function(){        Route::get("paper","PaperController@Index");    });});

The node table in 3.rbac is stored in this way.

Is it appropriate to have a specific interface address under a large node? Do you keep it that way?
Each new interface updates the table data. There is no other more elegant way of achieving it.

Reply content:

RBAC permission authentication.
Once a user logs on, it is not possible to query the database once per request.
1. Do you take all of the interface addresses that he has access to and then save them to the session?
2. In Laravel, some interfaces require authentication, some interfaces are open, I now route is so, there is no more elegant way to implement?

Route::group(['prefix' => 'api/v1'],function(){    Route::post('login',"AccountController@Login");    Route::group(['middleware'=>'auth'],function(){        Route::get("paper","PaperController@Index");    });});

The node table in 3.rbac is stored in this way.

Is it appropriate to have a specific interface address under a large node? Do you keep it that way?
Each new interface updates the table data. There is no other more elegant way of achieving it.

1-existence session inside is inevitable, so modify permissions after the corresponding user needs to re-login
2-did not study Laravel's RBAC, but the middleware seems to be very good, of course, you can also consider not to verify the route, but the final distribution when the completion of the verification (for example, when the controller was built to verify, Of course, this requires that path is a controller/action structure, not a routing address.
3-The data structure to meet the needs of the good, but you have a flaw, either use/start, or not all/start. As for each new interface to update the data table is inevitable, specifically to write a function of automatic synchronization on the line. Your data is clearly problematic, ID=25 's data pid should not be 4.

Added, another drawback of the design is that it does not define top-level permissions, which can be more cumbersome to manage. Usually we define a top-level permission, the other permissions are its direct/indirect child nodes, so that the admin user as long as the top-level permissions are OK, not affected by the interface data updates.

