Priority Model
Casbin prend en charge le chargement des politiques avec priorité.
Charger la politique avec priorité implicite
C'est assez simple : l'ordre détermine la priorité ; les politiques qui apparaissent plus tôt ont une priorité plus élevée.
model.conf:
[policy_effect]
e = priority(p.eft) || deny
Charger la politique avec priorité explicite
Voir aussi : casbin#550
Une valeur de priorité plus petite indique une priorité plus élevée. S'il y a un caractère non numérique dans la priorité, il sera placé en dernier au lieu de générer une erreur.
Le nom de jeton de priorité conventionnellement utilisé dans la définition de la politique est "priorité". Pour en utiliser un personnalisé, vous devez invoquer e.SetFieldIndex() et recharger les politiques (voir l'exemple complet sur TestCustomizedFieldIndex).
model.conf :
[policy_definition]
p = customized_priority, sub, obj, act, eft
Exemple de code Golang :
e, _ := NewEnforcer("./example/priority_model_explicit_customized.conf",
"./example/priority_policy_explicit_customized.csv")
// Due to the customized priority token, the enforcer fails to handle the priority.
ok, err := e.Enforce("bob", "data2", "read") // the result will be `true, nil`
// Set PriorityIndex and reload
e.SetFieldIndex("p", constant.PriorityIndex, 0)
err := e.LoadPolicy()
if err != nil {
log.Fatalf("LoadPolicy: %v", err)
}
ok, err := e.Enforce("bob", "data2", "read") // the result will be `false, nil`
Actuellement, la priorité explicite ne prend en charge que AddPolicy & AddPolicies. Si UpdatePolicy a été appelé, vous ne devriez pas changer l'attribut de priorité.
model.conf :
[request_definition]
r = sub, obj, act
[policy_definition]
p = priority, sub, obj, act, eft
[role_definition]
g = _, _
[policy_effect]
e = priority(p.eft) || deny
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
policy.csv
p, 10, data1_deny_group, data1, read, deny
p, 10, data1_deny_group, data1, write, deny
p, 10, data2_allow_group, data2, read, allow
p, 10, data2_allow_group, data2, write, allow
p, 1, alice, data1, write, allow
p, 1, alice, data1, read, allow
p, 1, bob, data2, read, deny
g, bob, data2_allow_group
g, alice, data1_deny_group
demande :
alice, data1, write --> true // because `p, 1, alice, data1, write, allow` has the highest priority
bob, data2, read --> false
bob, data2, write --> true // because bob has the role of `data2_allow_group` which has the right to write data2, and there's no deny policy with higher priority
Charger la politique avec priorité basée sur la hiérarchie des rôles et des utilisateurs
La structure héritée des rôles et des utilisateurs ne peut être que plusieurs arbres, pas des graphes. Si un utilisateur a plusieurs rôles, vous devez vous assurer que l'utilisateur a le même niveau dans différents arbres. Si deux rôles ont le même niveau, la politique (associée au rôle) qui est apparue plus tôt a une priorité plus élevée. Pour plus de détails, voir aussi casbin#833 et casbin#831.
model.conf:
[request_definition]
r = sub, obj, act
[policy_definition]
p = sub, obj, act, eft
[role_definition]
g = _, _
[policy_effect]
e = subjectPriority(p.eft) || deny
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
policy.csv
p, root, data1, read, deny
p, admin, data1, read, deny
p, editor, data1, read, deny
p, subscriber, data1, read, deny
p, jane, data1, read, allow
p, alice, data1, read, allow
g, admin, root
g, editor, admin
g, subscriber, admin
g, jane, editor
g, alice, subscriber
Demande :
jane, data1, read --> true // because jane is at the bottom, her priority is higher than that of editor, admin, and root
alice, data1, read --> true
La hiérarchie des rôles ressemble à ceci :
role: root
└─ role: admin
├─ role editor
│ └─ user: jane
│
└─ role: subscriber
└─ user: alice
La priorité ressemble automatiquement à ceci :
role: root # auto priority: 30
└─ role: admin # auto priority: 20
├─ role: editor # auto priority: 10
└─ role: subscriber # auto priority: 10