AuthorizationRules based on status of the object

mikemir8 posted on Friday, August 17, 2007

Looks like this has been asked many times for different scenarios, but I still haven't seen an answer I feel confortable implementing for my situation. First off, let me tell you this is the first application I'm planning on creating using CSLA, so I'm a newbie, bear with me =).

Basically, what I want to know is what's the best way to handle authorization rules per property that change depending on the object status.

Take the example of a helpdesk ticket. When the ticket changes its status (new, pending, working on, closed) the rules for accessing the properties might change for the different roles. Now, the AddAuthorizationRules method runs on the object creation, which happens before the object is fetched and the status is known.

This seems like a very straighforward question? Am I overlooking something obvious?

Miguel.

Marjon1 replied on Saturday, August 18, 2007

mikemir8:

Basically, what I want to know is what's the best way to handle authorization rules per property that change depending on the object status.

What you are looking for is the CanReadProperty / CanWriteProperty functions which can be overridden in your class. You can then build up the logic that you are looking for based on the values of the object itself. I've done this once for demo-project to only allow changes to certain properties (i.e. write permissions) when the object is new.

mikemir8 replied on Monday, August 20, 2007

Thanks for your reply. Overriding those functions is certainly one way of doing it. The issue I have with that approach is that it pretty much involves moving the authorization logic away from the AddAuthorizationRules function to a worker function. I believe that defeats the purpose of encapsulation.

What I'm curious about is why wasn't this implemented in the same way as Validation, where you can hook up you're on validation methods. So, besides having the regular AddAuthorizationsRules signature, you could also have one where you pass a delegate to the method you want to implement your logic.

I know I can take the CSLA code and change it to accommodate my needs. But I'd like to know if there is any valid reason not to do it this way.

- Miguel

JoeFallon1 replied on Monday, August 20, 2007

I believe this is #6 on the wish list.

http://www.lhotka.net/Article.aspx?area=4&id=42066ed8-ea65-44a3-b7fd-035c9d8bfa36

Make IsReadAllowed and similar methods call a delegate rather than user.IsInRole(). The delegate should be like Foo(user, role) and an app should be able to set that delegate globally

Joe

mikemir8 replied on Tuesday, August 21, 2007

That's good to know. Has anyone heard of when this might be implemented? I ask because almost a year ago Rocky mentioned he would "likely put it into 2.1.1 or 2.1.2" in this thread:

http://forums.lhotka.net/forums/thread/7244.aspx

- Miguel

paupdb replied on Monday, February 16, 2009

Sorry for reviving a dead thread, but I was wondering whether the above request ever made it into CSLA?

I'm in a position at the moment where being able to define Authorisation rules using a delegate, just like one would with Validation rules, is a fairly critical requirement.

Just want to see whether I need to implement this myself or whether this item is on a short list for a future CSLA version.

JoeFallon1 replied on Tuesday, February 17, 2009

Pages 363-364 of the 2008 book discuss the IsInRole Provider which is the delegate for IsInRole. You only have to make a config file change to enable a different behavior than the standard one. And of course you have to write the code that it is going to call instead of IsInRole. In my case I wanted it to call HasPermission(string permname).

It has been in Csla for a long time now. I originally requested it a while back.

Joe