RBAC 用户管理规范
概念：每个user有多个accounts，每个account 有一个account binding，有多个roles和多个tasks
举个例子：某个用户现在manager，这是admin添加了另一个角色supervisor的角色给他，数据结构是这样的（HdLogin）
user{
accounts : [
{
type : "administrator" //可以抽象或具体 ： administrator, manager
password : "1234",
roles ：[
{
type: "manager",
roleTaskss : ",manager,supervisor,"
},
{
type: "supervisor",
roleTaskss : ",supervisor,"
}
],
accountBindings : [
{
type : "email",
primaryKey : "[email protected]"
}
]
}
]
}
*primaryKey是email format， 电话号码，webchat。。。
*灰色是之前的需求，保留而已
自动登入，在employer page 登入后，会有cookies，去到candidate page时，会自动登入。过程是发现有cookies同时type 是customer。如果在candidate 登出时，employer 也会自动登出。因为在登出后，在refresh又会自动登入，死循环很奇怪！
半自动登入，在employer page 登入后，会有cookies，去到candidate page时，点击登入，在这里看当下页面的业务逻辑，
如果是只有一个角色可以登入的话，就直接帮他登入
如果是2个角色，就会有一个选项让他选择哪个角色，
如果是选择的角色在HdLogin有记入的话，会自动登入 （cookies是属于当下界面）
如果是选者的角色是不在HdLogin的话，会需要自己登入
手动登入，意思是每一个页面的业务逻辑都是只有支持自己页面的cookies。
当登入candidate page时，再去到employer page，会查找HdLogin，结果会发现没有记入，然后要求登入
account Type 会记入抽象或具体 user administrator，staff，manager...
举个例子：当manager登入admin page，之后再去到前台page，
如果前台page是“自动登入”或“半自动登入”，首先会去HdLogin去查找看看cookies有没有当下的页面
如果有记入，就broadcast
如果没有记入，就看记入中的account type是不是如何业务逻辑。现在account type是administrator，是可以登入的，在购买房间时，会确定角色是不是manager（因为业务只支持administrator 的 manager可以购买），然后完成！
但是如果是staff 呢？
举个例子：当staff登入admin page，之后在去前台page，
如果前台page是“自动登入”或“半自动登入”，首先回去HdLogin去查找看看cookies有没有当下的页面，
这时发现他的account type是administrator，是可以登入的，但是在购买房间时，资源会发现他不能访问，因为角色只有manager才可以购买
seek的概念，同个email，不同password
在结构上，user 是accounts的父层，但是在创建candidate email后再创建 employer email，是没有把这2个email在同个accounts！
完全是2个email。
roles的数据结构
举个例子：manager要操作supervisor的操作，这时必须roles.roleTaskss 添加一个supervisor。所有的manager就一定要有角色，不然会有bug！
roles ：[
{
type: "manager",
roleTaskss : ",manager,supervisor,"
},
{
type: "supervisor",
roleTaskss : ",supervisor,"
}
],