What are the implementation methods of Web background rights design?

Such as:
Menu 1

Menu 2

Menu 3
......

Design:
Table: Primary key, account number, password, permissions

  1    *    *   1，2  2    *    *   1，2，3  3    *    *   2  4    *    *   4

is to put the permissions into the "Permissions" field

What good way do you have?

Reply content:

Such as:
Menu 1

Menu 2

Menu 3
......

Design:
Table: Primary key, account number, password, permissions

  1    *    *   1，2  2    *    *   1，2，3  3    *    *   2  4    *    *   4

is to put the permissions into the "Permissions" field

What good way do you have?

This is simpler like ACLs (access control lists). Generally meet the needs of the project.

Somewhat more complex have RBAC (based on the color of the permission control).

PHP has a good RBAC implementation Phprbac

In general, ACLs are sufficient.

I am glad to answer the landlord's question.

The design of the authority system is essential for MIS system. Now many companies, have a universal access system of the entire solution, and the landlord proposed the authority design, is feasible, indeed there are a lot of mis is so dry, no problem. Yes, you also need to add a table to define permissions.

I used to do the system is to put the permissions in a separate field, with a char to put, each one represents a permission, and then write a helper class to set and get each permission.

My design is also a field to judge permissions, the pros and cons of this design do not have much depth of understanding, who have good insights to share under

1.ACL
2.RBAC

One thing to say: When using RBAC, people like to build a user and Role association table, in fact, directly role_id as a user attribute is the right path.

Welcome to the discussion.
Role and Node tables are many-to-many associations. Role A has 1, 2, 33 function points, role D has 1, 3, 53 function points, now a new feature 100, to the role of a role D has added new function 100 permissions. I'm talking about user and role-to-one relationships, and a role for users. U1 requires 1, 2, 3, 5, 100 these functions, set up a role E, role e associated with 1, 2, 3, 5, 100 these function points. The role property of U1 is set to E. If, in the usual way, U1 is associated with role A and role D, the function points of role A and role d are queried, and the merge is the right that U1 has.

Even if the authority system to QQ as complex, each level of QQ has a different function points, it is a role for each level, each QQ user level is unique. The role table has a maximum of 100 roles, not a user associated with a bunch of role.

Also, the frequency with which the new functionality of the system is added and the ability to get user-function permissions is certainly not comparable. The simpler it tends to mean high performance and robustness.

In general, many are using RBAC, even if it is not the same logic can do real-time verification and login verification of two

A person with a cross-section, authority is troublesome.

You can use RBAC.

