Returning data from dataportal even when a Authorization rule fails

bigface3 posted on Wednesday, December 05, 2007

I'd like to know if there is a way to get the dataportal to still load and return the object even though it may encounter a Authorization rule exception for one of the properties?

At first glance I've noticed if you add a AuthorizationRule.AllowRead (or DenyRead) for a particular property and give it a role that will fail, and you specify CanReadProperty("property", true) in it's getter, that when the dataportal fetches the object it throws the error back to the UI and the object is null.  Is the only way around this to change all the getters to code like this?

if (CanReadProperty("name", false))
 return _name;
else
 return string.Empty;

Of course returning string.Empty would only work for a string Property, other types would required their own default return value.  Which would mean that this type of code would have to be added to the BOs manually, not templatable?

As a side note, I tested out the ProjectTracker solution adding a AuthorizationRule.AllowRead("Name", "NoRule"); to the Project BO and ran the winform project (using Csla authentication), viewed a project, and Main.cs caught the exception and poped-up a dialog box, but the project form still loaded the rest of the data, is that done through the ReadWriteAuthorization control?

 

One more question! :-)  What is the diff between InstanceAllowRead and AllowRead?

ajj3085 replied on Wednesday, December 05, 2007

Well, I'm not sure what the DataPortal has to do with your Authorization exception.  In the DataPortal, you should be interacting with fields only.

As far as the UI goes, yes, the exception is a problem, and the getter code should be modified not to throw an exception.  That's because data binding attempts to read the value anyway.

InstannceAllowRead works on one instance of the object; say for Invoice #123, users in Role y cannot read a property.  AllowRead would enforce that rule on ALL instances of Invoice, regardless of their number.

HTH
andy

KeithElder replied on Wednesday, December 05, 2007

I think what he was saying is that the rules were getting checked on the application server and throwing an exception before it was getting data bounded.  Based on that the object was having its data put into it then something else obviously had to run to check the rules.  Are the rules check after the object is fetched every time?

KeithElder replied on Wednesday, December 05, 2007

Question on the InstanceAllowRead then. What is the best practice using the Instance* methods for rules.  For example if the business determines the a Manager can read the cost field for an item but other team members can't.  When an instance of that object is created there has to be some rule that says if the person looking at the instance of the object is a manager then allow the cost property to be read and vice versa not be read if they are not. 

Just curius how most folks handle that situation.