Priority Model
Casbin unterstützt das Laden von Richtlinien mit Priorität.
Richtlinie mit impliziter Priorität laden
Es ist ganz einfach: Die Reihenfolge bestimmt die Priorität; Richtlinien, die früher erscheinen, haben eine höhere Priorität.
model.conf:
[policy_effect]
e = priority(p.eft) || deny
Richtlinie mit expliziter Priorität laden
Siehe auch: casbin#550
Ein kleinerer Prioritätswert zeigt eine höhere Priorität an. Wenn es ein nicht-numerisches Zeichen in der Priorität gibt, wird es an letzter Stelle platziert, anstatt einen Fehler auszulösen.
Der konventionell verwendete Prioritätstoken-Name in der Richtliniendefinition ist "priority". Um einen benutzerdefinierten zu verwenden, müssen Sie e.SetFieldIndex() aufrufen und die Richtlinien neu laden (siehe das vollständige Beispiel auf TestCustomizedFieldIndex).
model.conf:
[policy_definition]
p = customized_priority, sub, obj, act, eft
Golang Codebeispiel:
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`
Derzeit unterstützt die explizite Priorität nur AddPolicy & AddPolicies. Wenn UpdatePolicy aufgerufen wurde, sollten Sie das Prioritätsattribut nicht ändern.
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
Anfrage:
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
Richtlinie mit Priorität basierend auf Rollen- und Benutzerhierarchie laden
Die vererbte Struktur von Rollen und Benutzern kann nur mehrere Bäume sein, keine Graphen. Wenn ein Benutzer mehrere Rollen hat, müssen Sie sicherstellen, dass der Benutzer auf verschiedenen Bäumen das gleiche Level hat. Wenn zwei Rollen das gleiche Level haben, hat die Richtlinie (die mit der Rolle verbunden ist), die früher erschienen ist, eine höhere Priorität. Für weitere Details siehe auch casbin#833 und 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
Anfrage:
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
Die Rollenhierarchie sieht so aus:
role: root
└─ role: admin
├─ role editor
│ └─ user: jane
│
└─ role: subscriber
└─ user: alice
Die Priorität sieht automatisch so aus:
role: root # auto priority: 30
└─ role: admin # auto priority: 20
├─ role: editor # auto priority: 10
└─ role: subscriber # auto priority: 10