Menu permissions issue?

The requirements are as follows: each user has different permissions. The first-level menu is displayed first, and then the mouse is moved under a certain first-level menu to display the corresponding second-level menu, and at most the second-level menu is displayed. The website uses three iframs, top, middle, and left, and the menu is in top. I thought of two options, but I felt they were both lacking:

The first is that when the user enters the website, the list of all menu permissions is obtained, forming a two-dimensional array. However, one disadvantage of this is that after modifying the permissions, it cannot be updated immediately as long as the website is not refreshed.

The second is that when the user enters the website, he first gets his first-level menu, and then when he clicks or slides to the first-level menu, he uses ajax to get his corresponding second-level menu. In this way, the permissions of the second-level menu can be updated immediately, but the first-level menu still cannot be updated all the time.

There are still a few problems, that is, he does not click through the menu list that appears, but by entering the URL, so there is no way to prevent it. One solution I thought of is that the controller inherits a public controller. Verify permissions in the public controller.

How do you usually deal with this?

ps: When I asked this question, the general process was clear to me, but there was one small detail that I wasn’t sure about. Thank you for your answers. Now I will post what I have understood below. I hope that students who encounter such problems in the future can give them a reference:

1. Role and permission association table

2. Administrator and role association table

3. The permission table stores the combination of controller and method (for example: user/index)

4. The controller inherits a public controller, performs permission verification in the initialization method, gets the current url and splits it to get the controller and method parts user/index, and gets the permission ID

5. Users get their own roles and check whether their roles have this permission ID;

Reply content:

The requirements are as follows: each user has different permissions. The first-level menu is displayed first, and then the mouse is moved under a certain first-level menu to display the corresponding second-level menu, and at most the second-level menu is displayed. The website uses three iframs, top, middle, and left, and the menu is in top. I thought of two options, but I felt they were both lacking:

The first is that when the user enters the website, the list of all menu permissions is obtained, forming a two-dimensional array. However, one disadvantage of this is that after modifying the permissions, it cannot be updated immediately as long as the website is not refreshed.

The second is that when the user enters the website, he first gets his first-level menu, and then when he clicks or slides to the first-level menu, he uses ajax to get his corresponding second-level menu. In this way, the permissions of the second-level menu can be updated immediately, but the first-level menu still cannot be updated all the time.

There are still a few problems, that is, he does not click through the menu list that appears, but by entering the URL, so there is no way to prevent it. One solution I thought of is that the controller inherits a public controller. Verify permissions in the public controller.

How do you usually deal with this?

ps: When I asked this question, the general process was clear to me, but there was one small detail that I wasn’t sure about. Thank you for your answers. Now I will post what I have understood below. I hope that students who encounter such problems in the future can give them a reference:

1. Role and permission association table

2. Administrator and role association table

3. The permission table stores the combination of controller and method (for example: user/index)

4. The controller inherits a public controller, performs permission verification in the initialization method, gets the current url and splits it to get the controller and method parts user/index, and gets the permission ID

5. Users get their own roles and check whether their roles have this permission ID;

There is a reference frame:
ThinkCMF

After reading its source code, the general idea is:

Database:

<code>1.角色表
2.角色权限表
3.权限表
4.用户表
</code>

Users can choose roles
Roles can choose permissions

Permissions:

<code>1.权限名称
2.是否是父节点
3.可以访问的url（这个就是控制权限的关键）
</code>

Controller:

<code>1.登录
2.主页
</code>

Ideas for controlling permissions:

<code>1.Login的Controller首先用户需要登录，然后给一个用户的id做session。
2.Index的Controller写一层父Controller，来做一系列的权限判断的操作（比较当前的url与数据库查询到的该角色对应的权限的url）
</code>

You’re done.

Type 1: It’s all like this, don’t pay attention to it. Usually those who modify permissions are either super administrators or users with permission management permissions. The former does not need to change his own permissions, and the latter should not have the permission to modify his own permissions (otherwise he will adjust himself to a super administrator). And if you modify someone else's permissions, that person doesn't know, and it will automatically take effect the next time he logs in.
Second type: Ajax is not recommended. In fact, the above question makes it clear, so this option can be passed directly.

Regarding the issue of direct access: Permission management is access permission management, not menu item display/hide management, so if your controller does not implement permission detection, it is purely a bug. The simple way is to check the requested action when the controller is initialized, and then perform permission detection. If it does not match, it will jump out directly.

thinkPHP has a ready-made background permission management system module http://www.cnblogs.com/tanteng/archive/2012/11/25/2787597.html
Laravel also has it. The poster can refer to it