I was under the wrong impression..
At least i told my teammates i knew how it works and told them that csla works as i though it would work.
A user is under 2 roles: frontoffice employee and administrator
In the role "frontoffice employee" he is revoked a rule for "WriteDenied" on a specific propertyinfo
But on the administrator rule he can do all whatever he wants.
- Login into our application automaticly gives all possible roles, the user doesn't select which one.
- When a user has rights under an role he can do read or write (even if the rights are denied under another role)
The last requirement won't work since it seems to be the other way around. If an user is denied a read or write under an specific role he won't ever be able to read or write it even if he is allowed under another role.
I've been debugging into code and bumped into the code in Csla.Security.RolesForProperty which uses IsInRole internaly, i won't adjust that ofcourse.
public bool IsWriteDenied(IPrincipal principal)
return AuthorizationRulesManager.PrincipalRoleInList(principal, WriteDenied);
Does anyone understand my problem?
Do u know a way to turn the behaviour the other way using the deny rules? Or any suggestions?
I think i'll have to add a deny rule only if the rule applies in both authorizationgroups.
I solved it by adding allow rules whenever i have one deny rule i just add all allow rules excluding the deny rule.
You should only need the Allow setups. Csla works by granting access to all by default. If you specify allow or deny, then the roles are checked. If you specify Allow, then any roles not in the list will be denied by default. An explicity Deny would however override an Allow.
In other words, the Deny rule is redunant; just call Allow for your administrator, and all users not in Administrator would be denyed by default.
yup, exactly the way i solved it
Copyright (c) Marimer LLC