Some ideas about permissions

There are two sets of options when you are ready to do the right. • Save all the points in the database that need to be controlled are called permission tables. It's basically some ID. Then a role table, the role corresponds to the permissions, the user corresponds to the role.

The second is a permission control method that was previously seen in a project. Users-roles-permissions, which are immutable, are changed: permissions do not use a bunch of data representation: Using binary is similar to "01011100110" such as a string to represent, after the user gets the data in the same way to parse, such as the first four represents a form, a page, The first four indicates that adding 0 is available 1 is unavailable.

Preliminary analysis of the difference between the two, first of all to say something common. There are some dead things to write about. The official point is that the extension is poor.

Difference: The first structure is clear and easy to maintain. But the user frequently queries, adds the unnecessary IO operation, the performance aspect will be much worse, especially the Web program.

Second: poor readability. Maintenance trouble. You may need to add some necessary information in the corresponding structure data in order to achieve the possibility of expansion, once the error, debugging is a nuisance. The advantage is that the place is small, if used in the Web can greatly improve performance. There may be less than 1kb for a user's permission information.

--------------------------------------------------------------------------------------------------

Then the ideal of the permissions should be extensible, and in the network transmission as much as possible to reduce the transmission of content, it is best to reduce the operation of the IO on this basis, so that the load of the parts can achieve a sense of balance. Of course, the most important thing is reliable and stable and can be used anywhere.

Extensible, can now think of seemingly also can only be the data like a class to save, in the future if a page or a form to add a need to control the button only need to be in the corresponding class inside add to the attribute is OK. The storage on the datastore takes the second way. But not fully replicated. On its basis to make changes, think of it seems that only the JSON format of the data can meet both ways of operation.

Structured to meet, can be deserialized. Can be extended, and the modifications do not affect the previous data. Of course, this inside should consider the size of the amount of data supported by JSON.

Another problem that can be overlooked is how to define this information in a class, or something that is structured. In the future if you want to add a button to a page to achieve something unrelated to the background, but also require only someone to see a class of needs. Re-modifying the program can certainly be done, but hopefully it can be made detachable. Just modify a configuration file, and the page is perfectly implemented.

I think of XML here. If I can save the Web site, or the structure information of the program into XML. Customize a writing specification that, in the future, will add all the information to this file as it is developed in such a way that the structure is similar to the following:

<project>    <pagename>        < elements id/>        < elements id/>    </pagename>    < Pagename>        < elements id/>        < elements id/>    </pagename></project>

The XML document is read in the Permissions Assignment page. The selected node is placed in the JSON string when it is saved. Put it in the database ...

If you do this, a project's permissions will only have one XML, one page to maintain this XML (development, add node, delete), a permission assignment (modification) interface. Add a role (varchar) to the database user table that holds the user's role attributes. A user may belong to more than one role, and most of the data here will be just one data. Do not exclude users with multiple roles, but such data will be very few, so here only need to be separated by commas, the program over there to do a bit of processing just fine. There is a field in the role table that holds the JSON data for that role. The JSON data corresponding to the corresponding role is obtained when the user logs in in the future. With a little calculation you can control the display of the elements of each page, show or hide ...

The privilege function is basically done here. It is important to note that the pagename in xml, the element ID, and the corresponding page of the coupling degree, a page name modification will directly result in the permission control invalidation, the modification of the ID will also be caused. In general, the name of the page will not change. May change only the element ID in the page. Additional tags can be added to describe the attribute. To determine the display of the corresponding element is hidden.

Some ideas about permissions