Concept: Management of users > Roles > Permissions (role-based access control)

RBAC User Management Specification

Concept: Each user has multiple accounts, each account has an account binding, multiple roles and multiple tasks

For example: A user now manager, this is admin added another role supervisor role to him, data structure is like this (Hdlogin)

user{    Accounts: [        {            type: "Administrator"//can be abstract or specific: Administrator, manager            password: "1234", 
     roles: [                {                    type: "Manager",                    roletaskss: ", Manager,supervisor,"                },                {                    type: " Supervisor ",                    roletaskss:", Supervisor, " }], accountbindings: [{type:" email ", PrimaryKey:" [EMA Il protected] "}" }]}      

*primarykey is email format, phone number, webchat ...

* Gray is the previous requirement, reserved.
automatically login, after employer page login, there will be cookies, go to candidate page, will automatically log in. The process is to discover that there is a cookie and type is customer. If the candidate is logged out, the employer will also be automatically logged out. Because after the log out, the refresh will automatically log in, the death cycle is very strange!

semi-automatic login , after employer page login, there will be cookies, go to candidate page, click Login, here to see the current page of business logic,
If only one character can log in, just help him log in.
If it's 2 characters, there's an option for him to choose which role,
If the selected character is recorded in Hdlogin, it will be automatically logged in (the cookie is the current interface).
If the role of the chosen person is not hdlogin, you will need to log in

Manual login means that each page's business logic is only cookies that support its own page.
When login candidate page, then go to Employer page, will find Hdlogin, results will find not entered, and then asked to log in

Account Type is credited to abstract or specific user Administrator,staff,manager ...
For example: When the manager is logged into the admin page and then goes to the front page,
If the front page is "automatically logged in" or "semi-automatic login", first go to Hdlogin to find out if the cookie has a current page
If it's in, it's broadcast.
If it is not, see if the account type in is not how business logic is. Now the account type is administrator, can be logged in, when buying a room, will determine whether the role is manager (because the business only support Administrator manager can buy), and then complete!
But what if it's a staff?
For example: When staff log in to admin page, and then go to the front page,
If the front page is "Automatic login" or "Semi-automatic login", first go back to Hdlogin to find out if the cookie has a current page,
At this point, he found that his account type is administrator, can be logged in, but when purchasing a room, resources will find that he cannot access, because the role only manager can buy

The concept of seek, the same email, different password
On the structure, user is the parent layer of accounts, but after creating candidate email and then creating employer email, the 2 emails are not in the same accounts!
It's a total of 2 emails.

Data structure of roles
For example: to operate supervisor, the manager must ROLES.ROLETASKSS add a supervisor. All managers must have a role, or there will be bug!.

Roles: [            {                type: "Manager",                roletaskss: ", Manager,supervisor,"            },            {                type: " Supervisor ",                roletaskss:", supervisor, "            }        ],   

Concept: Management of users > Roles > Permissions (role-based access control)