Database-driven rule concept

Database-driven rule concept

Old forum URL: forums.lhotka.net/forums/t/4597.aspx


esteban404 posted on Tuesday, April 01, 2008

Hi All,

I need to load some rules from a database using CSLA 3.0.4 and would like verify my thinking. I'll use per-type rules to minimize the hit.

For each business objects, I can use a DataTable field and load it via the dataportal on object instantiation. Then execute a filter expression against it to get return a string[] object to feed into the second argument of the AuthorizationRules.AllowWrite(string property, params string[] roles) method. I chose a DataTable since it's so easy to create one and returns the correct format for the arg. The only thing there was that it has to be filtered for each Allow,Deny rule. Not a real big issue, just change the expression.

Then load any instance rules if required.

Does this sound close? Too much overhead? I didn't show the full implementation here, but it seems to work in theory. I have another tricky instance authorization I need to think about after this. I thought about lists, but I would then need more than one to contain the properties, roles and Deny/Allow rules. The table seems to hold them OK.

Thanks in advance,

_E

JCSoRocks replied on Monday, April 21, 2008

Too bad you haven't gotten any replies!

I'm working on a similar concept although I decided that the database hits for every call would be too much for me because I plan on using the FieldManager and both property-level and object-level permissions. What I've settled on is similar to the ProjectTracker's RoleList. I've written a simple class that developers can run that uses reflection to populate the security database with a list of objects and their properties.

I'm planning on having a static RolePermissionList that's based on a dictionary that takes an object's type as the key and then returns a List of RolePermission objects which contain the permissions that the various roles have for the different properties within the object. This will then allow me to set which roles are allowed what permissions to which properties by passing the type of my current object to this class. So, each time an object is instantiated, rather than hitting the database to get the authorization information, it can hit the cached data in the static class. It's a little complicated, but it allows you to write business objects with almost no security code in them.

esteban404 replied on Monday, April 21, 2008

I didn't really expect many replies, but the concept does work. The company I'm doing this project for actually has a repository of training information with codes. These training codes of their have unresolved many-many issues so I run a job on SQL server to build/update another table daily (or on demand) to get new and changed training info. I grab the user id from the governing table and update my user table in SQL server then go from there. It's a kludge only an outer join monkey could love for sure.

A nice side effect is that this also will allow the system to add users that don't exist in their training matrix, but need access. That'll allow some expansion to the company intranet and other users for viewing, etc.

_E

Copyright (c) Marimer LLC