Csla Authorization based on business property

Csla Authorization based on business property

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


decius posted on Friday, November 07, 2008

I'm just curious how others handle this sort of situation:

I have an authorization rule that depends on how one of the business properties get set. Should I just make this a custom business rule? And if so, should I make it throw a Security Exception, or just treat it as a Csla.Validation.ValidationException?

 

SonOfPirate replied on Friday, November 07, 2008

I assume that by how the property gets set you mean the manner in which it is set and not the value it is set to.  If you are looking to validate the value, then either use one of the CommonRules or create your own if that doesn't fit.  If you are looking to validate the manner in which the property is set, then I'd use some sort of flag variable and create a custom rule method that evaluates the flag for whatever condition you are looking for and associate the method with the property so it is evaluated appropriately.

Perhaps you could explain the use case a bit more if this doesn't answer your questions.

 

decius replied on Friday, November 07, 2008

well the problem is that it's really supposed to be an authorization thing, but it depends on what the objects property is set to. basically it's like this:

if(myObject._someProperty == 0)

{

//The user is allowed to write to PropertyA

}

else

{

//The user is not allowed to write to PropertyA

}

 

I just wasn't sure if most people treat that as a BusinessRule as opposed to an AuthorizationRule.  From what I can tell, it seems you're saying that you'd treat it as a BuesinessRule?

JonStonecash replied on Friday, November 07, 2008

I would treat it as a validation business rule only if the user could do something to change the value of _SomeProperty. By that, I mean that your error message for property A can point to the explicit action that the user must take to make it possible to change the situation such that Property A is writable. 

This sounds like you would like the textbox for entering A to be disabled for some values of _SomeProperty, or at least made read-only.  I have not done this but it may be possible to change the property authorizations for property A whenever the value of _SomeProperty changes.  Might be worth a look at the CSLA source code.

Jon Stonecash

dlambert replied on Friday, November 07, 2008

Here's the scenario I've run into in the past.  Imagine the Project Tracker app, except you want the Project Manager role to include the context of the object when doing authorization.  So, given three projects (Pn) and three Project Managers (PMn), you might have a situation like this:

PM1 is the Project Manager for P1 and P2
PM2 is the Project Manager for P2
PM3 is the Project Manager for P3 and P1

You'd expect to evaluate CanWrite(P1, PM1) = True, and CanWrite(P1, PM2) = False, then, but you can't, because Authorization was all static.

Now, the last time I ran into this problem was way back in CSLA 2.0, and I haven't revisited this in CSLA 3.6, so things might be different now, but that was the issue back then.  In a scenario like this, of course, an Exception would certainly be some form of Security Exception, because there's nothing the user can do at this point to change my mind about whether they can access this object.

I don't know that there's a solution here, but with any luck, maybe I've clarified the problem.

JonStonecash replied on Friday, November 07, 2008

My "rule of thumb" for this is that if the person entering data can change the situation so that they can get work done, it is a validation error.  For example, if a particular number must be between 10 and 20 (inclusive), then I can output an error message that says "number has to be in the range 10 to 20".  The user can then decide if it makes sense to enter a number between 10 and 20 or cancel the entire operation. 

If, in your situation, the user can change their behavior and continue forward, then I think that it is a validation error.  If the user cannot adjust their behavior to achieve success, it is an authorization error. 

An example from my past: Each user is associated with a specific region.  Each user is also either a reader or a creator.  All users can look at the data for all regions.  A creator user may create data within their own region, but may not create, update, or delete data in a different region.  There are a few different ways to think about this.  One, you could think of this as an authorization issue: the "create" button is enabled only if the user is a creator and the value entered in the region matches the region of the user.  Two, you could think of this as a validation issue:  assuming that the user is a creator, entering a value for the region other than the matching region value is a validation error.  Three, you could simply fill in the region for the user from the user's region value and make the field read-only.  If possible, I like answer #3: make it difficult to make mistakes.  I like answer #1 less than #2 because #2 gives the user some information about what to do to fix the problem and #1 might not.

Just some thoughts.

Jon Stonecash

Copyright (c) Marimer LLC