Author | dishes
Hello, Hello, everyone, today to talk about user permissions. Some may feel that there is nothing to talk about user rights, the common market of RBAC permissions model more to go, you need a little rookie terms. Said this, I could not see piggy back lines of Pecs, believe it or not I who gave you this society to the point ruthless - beg you read. Ahem ... serious serious, I believe me, watching you there will be harvested, harvest Laikan I do not, do not cut demand.
First, what is the authority
Whether the end product B or C-terminal products, basic rights will appear. For example, almost common knowledge, Jane books and other content products, you only have to login to comment, thumbs up, you can not log in the browser; another example of knowledge paid or video products, you can only pay for a complete view of columns in the content, you can not pay Look at a few minutes; and then a bit more complex, is the enterprise-class products in all departments, positions, privileges of different users can operate are different.
Baidu Encyclopedia explanation of rights is: "In order to ensure the effective performance of duties, the incumbent must have, to be a matter of scope and extent of decision-making." Bit of a mouthful, and I will say to understand is the "can not do." I want to dirty the students to follow traffic rules, wear seatbelts, to guard against fatigue driving.
Permission by type into three categories: page permissions, operating authority, and data access. Page permissions is well understood is that we can not enter the page; operating authority for this page is CRUD buttons and other buttons can not operate; as for data permissions, different users is not the same as coming to see the data, such as R & D department can only see the data of R & D, product unit can only see the data products Division.
User rights control point is actually available to the user. In other words, the minimum unit is a functional point of privilege. If that point is the function of the house one by one on a locked room of a product or system likened to a house, only get the corresponding key before they can use the product.
After understanding the above information, we start thinking of products to design this product, according to the principle of first MVP launched version 1.0 user permissions.
Second, the user rights V1.0
The simplest user rights, is to directly correlate the user and function points.
This way we can be very flexible control of user rights. What the user wants permission, we put the corresponding function points assigned to the user, the user holding the corresponding key can open a room.
This permissions model in practical application scenarios, often for function points less product, for example, only the login restrictions, pay restrictions. If too much a product of function point, then this model will bring a very complicated operation to the user.
Imagine a scenario, assuming your a 5-storey hotel has a locked room 50, each layer is different ××× is responsible for room hygiene. Every time you have to find a bunch of keys from the corresponding floor room key, to the corresponding floor member ×××, just look very trouble. If the room some more, your operation will be magnified geometrically, to the time you will crash.
Is not smarter way yet?
Nature is there, based on the needs of our iterate the original permissions model.
Third, the user rights V2.0
As the person in charge of the hotel, I can put all the first floor rooms with keychain, to the first floor ××× member; strung together on the second floor, to the second floor ××× member; and so behind, so I do not need to try so hard every time to go from a bunch of keys inside.
We put some set of function point is called the role, and then assign appropriate roles to users, so that users have the appropriate permissions to function. This model is the common market RBAC permissions model.
This permissions model in practical application scenarios, but not much more for Function Point users scale products. Less function points, with a more convenient and more flexible version V1.0, why say it suitable for small scale users?
Imagine a scene again, or that hotel, and now each member ××× you squeeze their labor complaints, seven days, year-round, too tired. In order to quell public outrage, you decide each by 10 ××× room staff to be responsible for health, so that you will allocate 50 keychain. If you each 20, 50 then, 100 of it, you will immediately Tucao, TMD broken product, this product manager to drag me out of heaven.
Do not worry, soon iteration.
Fourth, user rights V3.0
In order to reduce your workload, you decided to put all keychain 1st floor are on the first floor ××× member of the studio, on the second floor of the second floor ××× member of the studio ... and so on (of course each floor ××× members can only enter the studio this floor). So long as it is a member of ××× floor studio, you can quickly get a keychain area of responsibility, and you no longer need to spend energy to assigned.
We have the same user rights are combined, called user groups, assign roles to users long after the group just fine, so that, as long as the users in the group would have under the same authority, thus reducing the tedious configuration process .
This model is appropriate permissions function point more, users are relatively large, and the single product case. Why the emphasis on relatively simple products it?
Well let's imagine ... why do I want to, I think baby will have a temper, and I do knife.
OKOKOK, Anyway, I'm talking about a real case.
Last year I took over a city in Hubei project, the project contains more than 20 educational apps to more than 1,000 schools in the city on the millions of students, teachers, parents use. When the students with the implementation of direct authority collapsed, more than 20 applications each school should be paired role, and each role is assigned exactly the same. You can do the math, probably to operate many times, anyway, my fingers are not enough.
Classmate classmate, do not get excited not excited, immediately iteration, now you can take away the knife!
Fifth, the user rights V4.0
We role in different product portfolio, called the role group, the role group by giving the user groups, achieve rapid configuration privileges.
This user permissions model for a larger scale, a number of product lines, more functional point of situation. Rest assured rest assured, I will not continue to assume, then go on the assumption of an estimated knife cut it off.
VI Summary
Analysis of so many, in fact, we can find, always common permissions model does not exist, only the most suitable to do the same product, not based on user needs, free to apply the formula template, the harm is unimaginable.
Careful students should find that, even how complex scenarios, user rights V1.0 version can be resolved, nothing more than a multi-user operating needs nothing more. But we do products, the complex is always left to their own, simply left to the user, so please believe the number of Lan, which has always been our minimum standard output.
Finally, imagine a scene, practical application, the same department (user groups) different people is not the same rights, privileges such as product director and general manager of product will be different, how to solve?