Simple permission Design

I did not know how to write the right to do OA.

Affected by the original coarse-grained permission control, so complicate the problem so I don't know how to write.

Original coarse-grained control permissions:

Write a filter, the scope of the filter map is the scope of the permission control. Visitors can only access the public part of the JSP or controller. The permissions of my example are divided into 3 places: Visitors, users, administrators. So write one or two filters. Verify the identity of the session or application before accessing the specified content, and then pass or not. Filter control multiple JSP mainly through the JSP naming specification and folder specification, the use of wildcard * implementation. Controlling multiple controllers is achieved primarily through the namespace of some prefixes.

Now the simple permissions control:

Take the current project as an example:

Now all of the JSP for the project is in the Web-info directory. What does this mean? We cannot access the JSP directly through the JSP's link address, but use the controller for redirection or forwarding to enter the corresponding place.

We have always thought of insufficient permissions to access and even see the module how is this implemented?

We refine each assignable permission to function. Features have several main fields: ID, corresponding URL (which is the controller's URL). Each user has access to all functions that are automatically assigned after logging in. How is control implemented? Is the use of the front-end page of the list or button, such as the use of El Display function content, so we will have permission to control the piece a bit of feeling.

Each user has different permissions? Menu and User tables

Too many users, a lot of users have the same permissions, so we can abstract out the role table. The user belongs to a role, and the role has a specific function.

Three tables?

The relationship between the three tables requires the maintenance of an intermediate table. So the most basic permissions control table comes out, 5 tables.

5 Table I think I can guess it already. 2 relational tables.

Deep Point articles:

Design of database structure for general rights management design

First, preface

The application of the rights management system should be used in three different natures,

A, permission to use

B, assigning permissions

C, Authorization permissions

This article only from the "Use Rights" and "assign permission" Two application level analysis, temporarily do not consider the "authorized permission" this.

Second, preliminary analysis of users and roles

When it comes to rights management, you should first think of, of course, design a user table, a permission table. This determines what kind of authority a person has.

Do the work will find that this design is too cumbersome, if all employees in the company have such permissions, everyone to configure? That's a very painful thing to do. So add a role table, put some people in a category, and then assign the permissions to the role. Users under the role also have permissions.

the relationship between users and roles is that one user can correspond to multiple roles, and one role can correspond to multiple users. Many-to-many relationships.

So need an intermediate table, I believe we are very familiar with, naturally will not have doubts.

Application Scenarios

With users and roles, you need to design your application scenarios, such as how many modules (System modules, project management modules, sales modules) an application has.

A module like this is an application scenario, with menus, operations, and so on.

Let's say we've designed it now, and the application scenario includes modules, menus, and actions, so there are six different relationships

1. One user can correspond to multiple modules, and one module can correspond to multiple users. Many-to-many relationships.
2. A user can correspond to multiple menus, and a menu can correspond to multiple users. Many-to-many relationships.
3. One user can correspond to multiple actions, and one action can correspond to multiple users. Many-to-many relationships.
4. A role can correspond to multiple modules, and a module can correspond to multiple roles. Many-to-many relationships.
5. A role can correspond to multiple menus, and a menu can correspond to multiple roles. Many-to-many relationships.
6. A role can correspond to multiple actions, and one action can correspond to multiple roles. Many-to-many relationships.

Six tables were created to maintain the six relationships.

The design looks fine. Yes, if you do not add a new relationship, you can already meet most of the requirements. But if it is, the new relationship (demand) tends to come into the system. At this point, we need to build a new table. The complexity of the system increases as well.

As you can see, there are several problems with this design:

1. Data table design too complex
2. Coping with system scenarios is too fixed

Three, to simplify the problem

Different applications, you may come up with different needs, after a new demand, you may find that the original design is not implemented, and then add a new table. This is also the problem mentioned above.

In fact, you don't have to be so complicated, permissions can be simply described as:

XXX subject has a certain authority in XXX field

1, the subject can be a user, can be a role, or it can be a department

2, the domain can be a module, can be a page, or it can be a button on the page

3, the permission can be "visible", can be "read-only" or "available" (such as a button can be clicked)

is actually the WHO, what, how problem

So the six tables mentioned above can actually design a table:

IV, example description

Here is an example of a design description. "User, role on page is permission to use"

Detailed design:

1, put the menu configuration on the database, each menu for a unique encoding Menuno, each "leaf node" menu item for a page (URL).

2, put the configuration of the button on the database, and belong to a menu item (in fact, is hanging on a certain page). A page might have several button groups, such as two lists, both of which need to have "add, modify, delete." So you need to add a button to group the fields to differentiate.

3, assign menu permissions to user/role, privilegemaster "user" or "role", privilegemastervalue as UserID or roleid,privilegeaccess as "menu", Privilegeaccessvalue to Menuno,privilegeoperation as "enabled"

4, Assign button permissions to user/role, privilegemaster "user" or "role", privilegemastervalue as UserID or roleid,privilegeaccess as "button", Privilegeaccessvalue to Btnid,privilegeoperation as "enabled"

5, Privilegeoperation is set to "disabled" if you need to prohibit the permissions of individual users.

If not clear can see:

Database design:

Four, the conclusion

Speaking so much, in fact I recommend only privilege table design. This table is the design of the WHO, what, how problem prototypes. Not only is extensibility, flexibility is good, but also the complex rights management system condensed into one sentence.

and privilegeoperation not only use and prohibit two, including the allocation of permissions, authorization permissions, can be defined with this field. It's just that it makes the design of the application more difficult, but it can be done without any modification to the table design, which shows its flexibility.

Objective

The design idea of "the subject"-"Domain"-"authority" (who, what, how problem prototype) is introduced in the previous article "The Database design scheme of the universal Rights Management Design"

This paper will further extend the design idea, and introduce the design scheme of data permission.

Permission control can be understood, divided into these kinds:

"Functional Permissions": What can be done, such as adding products.
"Data Permissions": The problem of what data can be seen, such as viewing all of my orders.
"Field permissions": Questions about what information you can see, such as vendor accounts, roles, departments, and so on.

The design mentioned above is "functional permission", this design has certain limitations, for the subject, can only be explicitly specified. For the ambiguous, there may be no way to deal with it here. For example, the following situations:

Data is visible only to current departments and superiors
Data is visible only to the current user (i)

Like this, you need to use the data permissions mentioned above.

Previous article I used a table five fields to complete the "Functional permissions" design ideas
This article will show you how to use a table of two fields to complete this "data access" design ideas

Preliminary analysis

Data permissions are further extended on the basis of functional permissions, such as the ability to view the scope of an order as a function permission, but you can see which orders are working with data permissions.

In the design, we stipulate that if the data permission rule is not set, it is considered to be allowed to view all the data.

Several concepts
"Resources": Control objects for data permissions, various resources in the business system. such as order documents, sales orders and so on. Belonging to one of the "fields" mentioned above
"Subject": User, Department, role, etc.
Conditional rule: A conditional definition for retrieving data
Data rules: Conditional rules for data permissions

Application Scenarios
1, order, can be viewed by me
2, the sales order, can be viewed by oneself or superior leader
3, sales orders, sales staff can view their own, Sales Manager only view sales amount greater than 100,000.

We can think of a straightforward method, which is implemented by adding SQL where conditions to the Access data entry, and organizing SQL statements:

1,where UserID = {Currentuserid}
2,where UserID = {Currentuserid}  or {Currentuserid} in (leader)
3,where UserID = {Currentuserid}  or ({Currentuserid} in (Sales Manager) and  Sales Amount > 100000)

These one-to-one "conditions", this article is simply understood as a "data rule", usually with the original foreground of our business filter to merge and then retrieve the data.

This is one of the most straightforward implementations, with a "data rule" on "resources" (such as the three points above). This design is

"Resources"-"data Rules"

I also think that different people should correspond to different rules, then it can be understood that a user corresponding to different roles, each role has the same "data rules", then the design becomes

Resources-principals-data rules

Depending on the provider, prepare different permissions to respond to the policy.

Here is a simple introduction, this scheme requires at least 2 tables, one is "resources, principals, rules and relations table", and a "Data rule table"

The relationship table cannot save the role directly because you are not sure when the business needs to define the data rules by "department" or "branch office"

So you can use the Master, masterkey similar two fields to determine a "body"

This is configured in XML mode (similar to the database):

<?xml version= "1.0" encoding= "Utf-8"?>
<settings>
  <rule view= "Orders" role= "Sales Staff" >
      Sales clerk = {Currentuserid}
  </rule>
  <rule view= "Orders" role= "Total Sales Manager" >
     Sales Amount > 100000
  </rule>
  <rule view= "Order" role= "Regional Sales Manager" >
    Sales Amount > 100000 and  region = {Current user's Region}
  </rule>
</settings>

Friends interested in this way can also try, the two ways of the "data Rules" is the same, but this article does not adopt the second design, because it has a layer of processing logic, I think should design the simpler the better, take the first way:

"Resources"-"data Rules"

Of course, the above is a SQL way to determine the condition rules, we certainly do not do so. Although SQL is flexible, it is difficult to maintain, and we do not know how SQL is embodied in our interface UI. Difficult to display directly with a text box. This is not a problem for a developer, but the system administrator is prone to problems. So we need to have another way to determine this rule and eventually convert it to our SQL statement.

The key to our design is how to standardize these "data rules", which must be friendly to the front-end and friendly to the backend, and JSON is clearly a good way.

Rule description:

1, data permission rule always: {attribute condition allowed value}

2, data permission rules can be merged. For example ({Current user belongs to salesperson} and {order salesperson equals current user}) Or {Current user belongs to Sales Manager}

3, eventually we'll use the JSON format

When retrieving data, you will first determine if there is a "condition rule" for a certain "resource", and if so, load the "conditional rule" and merge it into the "search criteria" in our foreground (your business interface should have a search box)

If the search box for customer information is defined, we search for a customer ID including an, and the rules we organize will be:

{"Rules": [{"Field": "CustomerID", "Op": "Like", "value": "An", "Type": "string"}], "OP": "and"}

To better understand the "data rules", here's a look at "Common query mechanism"

"Common query mechanism"

Permission control can not always be separated from a number of conditions (such as viewing the current department of documents), if there is no perfect general query rules mechanism, then in the permission conditions to filter the time you feel very awkward. This article describes a common query scenario, and then describes how to implement the data rules.

Earlier, I wrote an article about Ligergrid combined. NET design common processing class, "JQuery Liger UI Ligergrid Create a common paging order query form (available for download)". The filtering information mentioned is a direct SQL statement. This is unreliable and unsafe.
The filtering information that is transmitted to the background at the front end should not be a direct SQL, but rather a set of filtering rules. In Ligerui V1.1.8 has added a conditional filter plug-in, which consists of the rule data is my recommended:
such as the following

{"Rules":
[
{"Field": "OrderDate", "OP": "Less", "value": "2012-01-01"},
{"Field": "CustomerID", "OP": "Equal", "value": "Vinet"}
]
, "OP": "and"}

Rule description:
Find customer vinet documents with orders less than 2011-01-01

Such data is secure and generic (you can even add an or subquery). Whether you're on the front or the back, whatever component you use, it's good to use.

Generic background translation, you can generate such SQL parameters:

Text:
([OrderDate] < @p1 and [CustomerID] = @p2)
Parameters:
P1:2012-01-01
P2:vinet

Here's something complicated: Find customer vinet or TOMSP, all documents with orders less than 2011-01-01

{
"Rules": [{"Field": "OrderDate", "OP": "Less", "value": "2012-01-01"}],
"Groups": [
{"Rules": [{"Field": "CustomerID", "OP": "Equal", "value": "Vinet"}, {"Field": "CustomerID", "OP": "Equal", "value": " Tomsp "}]," OP ":" or "}
],
"Op": "and"
}

Translation results:

Text: ([OrderDate] < @p1 and ([CustomerID] = @p2 or [CustomerID] = @p3))
Parameters:
P1:2012-01-01
P2:vinet
P3:tomsp

This filtering rule is divided into three parts: "Grouping", "Rule" (field, value, operator), "operator" (and OR), and itself a grouping.
This simple structure can satisfy the whole situation.

Of course, the above mentioned conditions are defined in the foreground (may be the user in the search box input), and in the background, we may define the "hidden conditions", such as "employees can only see their own", how to do it, in fact, is very simple, just need to receive this filter in the background (foreground Tojson, Background parsing JSON), plus a filter rule (hidden condition):

{field: ' EmployeeID ', op: ' Equal ', value:5}

The original filter rules can be added as a grouping:

{op: ' and ', groups:[

{"Rules": [{"Field": "OrderDate", "OP": "Less", "value": "2012-01-01"}],
"Groups": [
{"Rules": [{"Field": "CustomerID", "OP": "Equal", "value": "Vinet"},{"field": "CustomerID", "OP": "Equal", "value": " Tomsp "}]," OP ":" or "}
], "OP": "and"}

],rules:[{field: ' EmployeeID ', op: ' Equal ', value:5}]
}

Translate as follows:

Text:
([EmployeeID] = @p1 and ([OrderDate] < @p2 and ([CustomerID] = @p3 or [CustomerID] = @p4)))
Parameters:
P1:5
P2:2012-01-01
P3:vinet
P4:tomsp

Such a "conditional rule" is what we want, not only in the front-end can be well resolved, but also in the background processing. In the background we define the class that corresponds to this data structure, and then we define a class that translates to sql:

Data permission Rules

Having said this, you can begin to describe how to implement the "Data Rules":

The "hidden conditions" mentioned above are the "data rules" I introduced.
Think of some, so that the filter rules of the foreground, coupled with our defined "Data permissions" control filtering conditions. No, it's the end of the meeting.
Let's look at these "data rules" that we've saved in our database:

Can't you see? Well, here's a little clearer:

Rule description

Order: "Order manager and demo role can view All", "order Viewer" can only view their own

Products: "Basic information entry and presentation roles can view all", "suppliers" can only view their own

{Currentemployeeid} represents the current employee.

In essence, we can also define the required parameters based on the current user information, such as:

{Currentuserid} Current user ID, corresponding to table ' Cf_user '

{Currentroleid} current role ID, corresponding to table ' Cf_role '

{Currentdeptid} Current user department ID, corresponding to table "Cf_department"

{Currentemployeeid} Current user employee ID, corresponding to table "Employees" (Cf_user.employeeid)

{Currentsupplierid} Current user vendor ID, corresponding to table "Suppliers" (Cf_user.supplierid)

We save these user parameters directly in the database and replace them when the "translation" rule becomes sql:

For example, to view an order, we get the SQL, which may be:

Text:     SELECT * FROM (select top of * from "[Orders] WHERE (1=1  and (@p1 in (@p2, @p3)) or (@  P4 = @p5 and [EmployeeID] = @p6)))) (Order by OrderID ASC) as Tmptableinner order by OrderID DESC) as Tmptableouter order by OrderID ASC     
Parameters:
@p1 [Int32] = 7
@p2 [Int32] = 2
@p3 [Int32] = 6
@p4 [Int32] = 7
@p5 [Int32] = 7
@p6 [Int32] = 1

{Currentruleid} is replaced with 7

{Currentemployeeid} is replaced with 1

We design the "Data Permissions" interface, you can select all the fields, including several user information:

These fields do not just enter values in the text box, you can customize the data source:

var fieldeditors = {};
fieldeditors[' Orders '] = {
    
        Options: {
            WIDTH:200,
            URL: ".. /handler/select.ashx?view=orders&idfield=shipcity&textfield=shipcity&distinct=true "
        }
    }
};

Effect interface:

Practical application

Since it is data rights control, if there is a unified data reception portal, we can use this portal to do some work.

For example, "LIGERRM Rights Management System" Unified use of GRID.ASHX this data processing program as a list of data receiving portal.

With a unified interface, easy to do permissions control, the use of Ligergrid JavaScript tables, or similar plug-in friends, should be more clear about the server interaction principle.
In the GRID.ASHX, we will pass
View/table name, sort information, paging information, filter information
These several indicators to get the specified data.

In the actual business, the control of permissions may be introduced. such as a "resource", can only be viewed by the current user itself, or can only be viewed by the current user department and the parent department. For these controls, we take the form of registering a set of "conditional rules" for these "resources" that might do permission control.

We will find the "Data permission rules" defined by the view and merge them with the "search rules" entered by the user in the foreground search box:

The above code is an example of data condition merging, so that we can get the filtering rules we need eventually.

The above article from: http://www.cnblogs.com/leoxie2011/archive/2011/05/19/2050626.html

Copy to Here is afraid of the master deleted. Thank you.

Simple permission Design