Moved here
for nearly 4 months without updating this series. This series is my superficial understanding. I feel that some of the ideas are not optimal and do not conform to mainstream concepts, because I did not learn concepts such as rbac, which are for reference only. Especially for the processing method of permission design, casbin tries to use its own query method as much as possible, because that is to directly check (add, delete, modify) the memory (map), and should not check (add, delete, modify) the database, This must be avoided. Many of the articles in this series make such mistakes. When reading, you should avoid making such mistakes according to your own scene.
The second half of this time is based on the permission design of onlyoffice that I just wrote. This permission design is quite novel as a whole. It is written after the onlyoffice community. The empowerment of documents, whether it is a user or a role, corresponds to 4 permissions. , in one go, I use bootstrap table's x-editable and select2 for drop-down selection, real-time batch settings and individual switching permissions, very free and casual.
Policy updates include user role updates, and permission updates for users or roles. The methods in rbac_api.go and management_api.go of casbin seem to be divided into several "levels": such as addrole and addpermission, which are special; AddNamedPolicy is similar to this general.
Another example is GetPermissionsForUser, which is different from enforce(), which can realize: user belongs to role, user has permission to access data1, and role has permission to access data2. At this time, use enforce(user, data2), the result is true, but use GetPermissionsForUser(user), it can't get the data2 of the role. It can only be used to first take out all the roles of the user, and then cycle to take out the permissions that each role has.
[plain] view plain copy
roles := e.GetRolesForUser(useridstring) //Get all the roles of the user
for , w := range roles {
roleRes = e.GetPermissionsForUser(w) //Get all the permissions of the role
for , k := range roleRes {closer to the topic
, the general idea of policy modification should be as follows:
1. To update a user's role, first delete all the user's roles, and then re-add the user's role.
2. To update the permissions of a user (or role), first delete all the permissions of this user for a certain file, and then add it again, the same reason.
The first is the modification of users and roles: as shown in the figure below, click on the user, and the roles of this user are displayed below, and checked.
When the modification is checked, and then save, the backend first deletes all roles of this user with e.DeleteRolesForUser(uid). Then add it cyclically according to the incoming backend selected in the previous paragraph.
[plain] view plain copy
//Add user roles
//Delete all user roles first
func (c *RoleController) UserRole() {
//To support batch assignment of roles, loop user id
uid := c.GetString("uid") //secofficeid
//First delete the user's authority
e.DeleteRolesForUser(uid) //The database is not deleted!
//Delete the user in the role in the database
o := orm.NewOrm()
qs := o.QueryTable("casbin rule")
, err := qs.Filter("PType", "g").Filter("v0 ", uid).Delete()
if err != nil {
beego.Error(err)
}
//Add, if there is no selection, it is equivalent to delete all role
ids := c.GetString("ids") //roleid
if ids != "" {
array := strings.Split(ids, ",")
for , v1 := range array {
e.AddGroupingPolicy(uid, "
//should use AddRoleForUser()//rbac_api.go
}
}
c.Data["json"] = "ok"
c.ServeJSON() }
Permission update for a document in onlyoffice
Select a document and click the permission button to display the user, role and corresponding permissions of the document.
For the document /onlyoffice/26, when users and roles are deleted or added, they are sent to the background. First, use RemoveFilteredPolicy to delete all policies whose v1 is /onlyoffice/26 in the CasbinRul table.
Then re-deposit according to the passed strategy. Because the user and role are placed in a table, so we need to distinguish, the role id plus role_ to show the difference.
[plain] view plain copy
e.RemoveFilteredPolicy(1, "/onlyoffice/"+strconv.FormatInt(attachments[0].Id, 10))
:= orm.NewOrm()
qs := o.QueryTable("casbinrule")
, err = qs.Filter("v1", "/onlyoffice/"+strconv.FormatInt(attachments[0].Id, 10)).Delete()
if err != nil {
beego.Error(err)
}
/再添加permission
for , v1 := range rolepermission {
// beego.Info(v1.Id)
if v1.Rolenumber != "" { //存储角色id
success = e.AddPolicy("role"+strconv.FormatInt(v1.Id, 10), "/onlyoffice/"+strconv.FormatInt(attachments[0].Id, 10), v1.Permission, suf)
} else { //存储用户id
success = e.AddPolicy(strconv.FormatInt(v1.Id, 10), "/onlyoffice/"+strconv.FormatInt(attachments[0].Id, 10), v1.Permission,suf) //AddPermissionForUser() should be used here, from casbin\rbac_api.go
}
}
RemovePolicy and RemoveGroupingPolicy can be used according to their own scenarios.
In the above example, the casbin method was used to delete the in-memory policy. Correspondingly, it will automatically delete the data in the database, but it cannot be solved temporarily, so the data in the database will not be automatically deleted, so a piece of code is added for Delete database data.
Casbin is very convenient for judging the permissions of users. However, due to many scenarios, for example, sometimes it is necessary to display the permissions of a logged-in user to each resource (below):
Sometimes the administrator needs to know all the users and roles of a resource, and the corresponding permissions, as shown in the following figure.
There are also a few common questions:
1. The user's permission (action) is represented by 1, 2, 3, 4 or get, post, ... because sometimes it is necessary to grade and prioritize, if you add another field, you may not need it. For example, for a document, all permissions are specified as 1, comments as 2, read-only as 3, and disallowed as 4. When setting the permission, directly set the permission to read-only 3 for this user, and this user belongs to the role role, the role's permission to this document is 1, then this user should have the highest permission priority. Therefore, it is more appropriate to use 1234. After converting to int, you can do the comparison and take the smallest one.
2. Casbin should have no special treatment for admin, just set it like a normal role.
3. In addition, casbin supports ip segment. This I have also found a piece of ip segment processing code on the Internet before. It seems to be an ip scanner code. First, the segment is turned into one ip, corresponding to the port number, and then written into the map, in the memory. It is similar to the way of casbin.
Next, there is an immature idea: put the conf and csv in the casbin example into a file one by one, add comments, and if possible, add methods such as additions, deletions, and changes. This makes it easy for beginners to directly enter the examples, or to find examples in their own scenarios directly here. In addition, there are some ideas of casbin. I understand them all together. They do not represent official ideas. Why is this behind its processing methods?