I am transitioning from CSLA3 to 4. The new eBooks only really talk about IsInRole. I liked how the old CSLA used AccessGroups and Roles.
i.e. "Administrator" group access could have many "Role" types. "Job_Read", "Job_Write", "Task_Read", "Role_thatAllowsYouToDoSomethingElse".
The new membership seems to just have Roles categorized like "Administrator", "Power User", "Standard User"...
//Here is a standard way to set authorization permission for a user to read the "CityProperty" in CSLA4
BusinessRules.AddRule(new Csla.Rules.CommonRules.IsInRole( Csla.Rules.AuthorizationActions.ReadProperty, CityProperty, "Administrator", "Power User"));
//The old CSLA 3 would do something like this, where "CityName_Read" is a role type the user is in.
In the CSLA3 way, both Administrator and PowerUser could be in the "CityName_read" role.
Is it possible to mimic the way CSLA3 handled Authorization? Perhaps making a custom rule for each and every property? (could be quite time prohibitive doing it this way?)
Actually.... thinking back to when I first setup my original CSLA 3 project I may have just blurred the use of "Role" by labeling each role like "CityName_Read", "CityName_Write", etc.... then implemented my own List for "AccessGroup" and "IsInAccessGroup" method in the Identity object.
Can anyone see any performance issues with having a huge number of "Roles" loaded into the Identity object? Using many roles in an MVC stateless environment may slow things down a little?
(it was a long time ago)...
The Autorization part works just the same as before - so this is just as valid for CSLA 4:
I wouldn't worry so much about loading many roles - just to make sure that loading is very efficient and maybe cached on the server.
As a suggestion, our roles are enumerated in an enumeration and we store them as a bit array in order of the enumeration on the identity. Since it's passed on each call I would echo Jonny in keeping it efficient and lightweight.
Hi skagen00, The enumeration sounds interesting. Does it make the code any less readable doing it your way?
No not at all, because IsInRole is just what is exposed and the implementation to handle the bit array is encapsulated within the identity/principal.
Since it's an enumeration, IsInRole is called with our RolePermission enumeration values.
The method on our identity (we end up actually invoking it w/ an enumeration on a static class, not usually directly) looks like this. Permissions is our bit array.
bool ICheckRoles.IsInRole(string permissionName)
if (!Enum.TryParse<RolePermissions>(permissionName, out permission))
int index = (int)permission;
if (index < 0 || index >= Permissions.Length)
Hi JonnyBee, Thanks for the response and the link, This is exactly how I have previously implemented permissions. I had just forgotten that I took this tact.
It's great to know that it is also a recommended solution.
Copyright (c) Marimer LLC