Authorize Read/Write on the Property level based on data

Authorize Read/Write on the Property level based on data

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


wentwj posted on Thursday, April 10, 2008

On the project we're working on we have a need to restict access to objects based on the state of the object itself.  For example we want a certain property to be writable only if the object is new, or only if the object has a certain 'status', or any set of restrictions based on the property itself.

We also want these conditions to be reflected based on the result of CanReadProperty and CanWriteProperty in order to pass this information up to the UI and any other program that consumes the business objects.   Basically we want to be able to add authorization rules based on the state of the object rather than  specific role the user has.

Is there a way to handle this within CSLA?

RockfordLhotka replied on Thursday, April 10, 2008

You can override CanReadProperty() and CanWriteProperty() to change their behavior.

wentwj replied on Thursday, April 10, 2008

We were developing an addition to our CSLA framework, which is essentially a combination of AuthorizationRules and ValidationRules as a new AuthorizationBusinessRules class on each of our business objects.  It maintains a collection of handlers similar to ValidationRules, which is called through overload CanReadProperty/CanWriteProperty.  The handers simply accept an object which would be the instance of the of the buisness object that we'd be determinig if we should authorize the read/write.  So CanReadProperty/CanWriteProperty is overloaded to check these AuthorizationBusinessRules and then check the standard role authorizations.

Developers could then define AuthorizationBusinessRules in an AddAuthorizationBusinessRules function, which is executed once per type, similar to AddAuthorizationRules and AddBusinessRules.  So there's a slightly more structured way to define these object state based rules.

We were wondering what your thoughts would be on such an addition, and if there were some potential issues with this that we haven't forseen.

Copyright (c) Marimer LLC