Modèle de priorité

Casbin supporte les politiques de chargement avec priorité.

Politique de charge avec priorité implicitement

C'est assez simple, l'ordre détermine la priorité, la politique apparue plus tôt a une plus grande priorité.

model.conf :

[policy_effect]
e = priorité(p.eft) || nier

Charger la politique avec la priorité explicite

Voir aussi : casbin#550

The smaller priority value will have a higher priority. If there's a non-numerical character in priority, it will be in the last, rather than throw an error.

Token name convention

The priority token name in policy definition is "priority" conventionally. A customized one requires invoking e.SetFieldIndex() and reload policies (full example on TestCustomizedFieldIndex ).

model.conf :

[policy_definition]
p = customized_priority, sub, obj, act, eft

Golang code example:

e, _ := NewEnforcer("./example/priority_model_explicit_customized.conf",
                    "./example/priority_policy_explicit_customized.csv")
// Due to the customized priority token, the enforcer failed 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`

Maintenant, la priorité explicite ne prend en charge que AddPolicy & AddPolicies, si UpdatePolicy a été appelée, vous ne devriez pas changer l'attribut prioritaire.

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

Politique.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

Requête:

alice, data1, write --> true // pour `p, 1, alice, data1, write, allow` a la plus haute priorité
bob, data2, read --> false
bob, data2, write --> true // for bob has role of `data2_allow_group` which has right to write data2, et il n'y a pas de politique de refus avec une priorité plus élevée 

Politique de charge avec priorité basée sur le rôle et la hiérarchie des utilisateurs

La structure héritée des rôles et des utilisateurs ne peut être que de multiples arborescences et non des graphiques. Si un utilisateur a plusieurs rôles, vous devez vous assurer que l'utilisateur a le même niveau dans différentes arborescences. Si deux rôles ont le même niveau, la politique (le rôle correspondant) est apparue plus tôt a une plus grande priorité. plus de détails voir aussi casbin#833 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 

Politique.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 

Requête:

jane, data1, read --> true // jane est en bas, donc la priorité est supérieure à l'éditeur, admin et racine
alice, data1, read --> true

La hiérarchie des rôles comme 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