Rbac permission authentication, is user permission saved in session?

  mysql, question

Rbac permission authentication.
After a user logs in, it is impossible to query the database once for every request.
1. Do you want to take out all the interface addresses that he has permission to and save them in the session?
2. In laravel, some interfaces need authentication and some interfaces are open. My route is like this. Is there a more elegant way to implement it?

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

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

clipboard.png
Is it appropriate to have a specific interface address under a large node? Is this how you keep it?
Every time an interface is added, the table data must be updated. Is there any other more elegant implementation?

1- It is inevitable to exist in the session, so the corresponding user needs to log in again after modifying the permissions.
2- I haven’t studied rbac in laravel carefully, but it seems quite good to use middleware. Of course, you can also consider not verifying when routing, but when the final distribution is completed (for example, verifying when constructing controller, of course this requires path to be controller/action structure instead of routing address)
3- It’s good to meet the demand in data structure, but you are flawed. Either you start with/or you don’t start with/at all. As for updating the data table every time a new interface is added, it is necessary to write a special function for automatic synchronization. There is obviously a problem with the data in your screenshot. The data pid with id=25 should not be 4.

Add that another disadvantage of the design is that there is no definition of top-level permissions, which will be more troublesome to manage. Usually, we will define a top-level permission, and all other permissions are its direct/indirect child nodes, so admin users will be ok as long as they have the top-level permission, and will not be affected by interface data update.