Csla binding property-get and swallowed SecurityExceptions

Csla binding property-get and swallowed SecurityExceptions

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


trp956s posted on Tuesday, July 14, 2009

Hello,
I am new to CSLA and have just completed my first attempt to bind a control to a field. As a test scenario I made the field inaccessible by setting the security for get to false. However, I did not see the anticipated behavior.

The form displayed as usual and the textbox appeared as happily as ever. However there was no text displayed in the textbox. So perhaps the textbox did not get bound after all.

I would like to be able to detect security access in my application in an elegant way once and for all bound properties as I have seen in the latest version of CSLA. We have the latest version but our code was written from your last book, Expert C# 2005.

Please tell me how I can make binding work with security for my application using Expert C# 2005.

Thank you.
-Tom

skagen00 replied on Tuesday, July 14, 2009

CanReadProperty takes a boolean as to whether or not to throw an exception (or to swallow it).

GetProperty, since it includes the security check of CanReadProperty, provides a boolean in some of its overloads.

The default behavior is to not throw an exception for getting a property.

rfcdejong replied on Wednesday, July 15, 2009

Are u binding in WPF or old winforms?

WPF binding swallows exception as well, but u can see them in the output window.

trp956s replied on Wednesday, July 15, 2009

I am binding to WPF 3.5 forms. I'm aware of WPF swallowing exceptions on get and about how to tell CSLA to swallow an exception. I don't want to distract my UI developers much from their current work so I would like to program this functionality into our internal WPF base classes. My users won't have an output window so I don't have the option of notifying them about their security violation via the output window.

I was hoping there was a way I could make WPF pay attention to the security restraints without having to modify each bound field to bind also the enabled property and the visible property to obj.CanEdit( propertyName ) and obj.CanRead( propertyName ) respectively.

We already have dozens of forms and controls and dozens of developers making more now so I need a viable, maintainable solution that works for our users and our developers.

Maybe later versions of CSLA have found a way around this barrier. If you know it please point me in the right direction.

Thanks,
Tom

rfcdejong replied on Wednesday, July 15, 2009

Perhaps Bea Stollnitz blog can provide some help for you on how to know WPF binding errors.
Adding a tracelistener and setting the tracelevel higher.

http://www.beacosta.com/blog/?p=52

There is a link to a blog from Pete Blois having a tool for this called "Snoop"

http://blois.us/blog/2006/08/long-time-since-my-last-post-but-dont_21.html

I hope this is a step into the right direction.

Greetings,
Raymond de Jong

trp956s replied on Wednesday, July 15, 2009

Thank you all for your help but I am trying to find a solution that will work for my users and many of the solutions presented seem to focus on debugging the exception thrown by the property get. I already know what the exception is: it is a security exception thrown by design because the test user was purposefully set up to be denied read access to a property on an object as part of an effort to understand how CSLAs security model might work with bound WPF controls.

It seems that our version of CSLA requires additional effort when binding object properties to WPF controls.

The problem I am facing is how to reconcile WPF and how it wants to handle exceptions and CSLA and how it wants to handle security. Right now we are considering a refactoring of all of our bound controls so that they bind to the CSLA security model for Visibility and IsEnabled to .CanRead and .CanWrite respectively. The number for forms and fields we have makes this a large and expensive undertaking.

The latest version of CSLA uses a security model that works with WPF with little effort (as I understand it - I haven't used it). Is it possible to integrate this new functionality into my application without updating the WPF forms?

Thanks again,
Tom

RockfordLhotka replied on Thursday, July 16, 2009

The behavior of GetProperty() and SetProperty() is documented in the Expert 2008 Business Objects book.

At a high level, these methods are designed to make it as easy as possible to work with data binding in WPF, Windows Forms, Silverlight, etc.

It turns out that data binding will attempt to read a property as long as the property is bound to a control - even if the control isn't visible.

So even if the UI developer did the right thing by disabling or hiding the UI control (assuming the user wasn't authorized to read the value), data binding would still attempt to read the value - causing an exception. Not all UI technologies silently ignore that exception, so in some cases this would mean the app would fail!!

To avoid that issue, GetProperty() doesn't throw an exception when the user isn't authorized. Instead, it returns a default value (usually an empty string or 0) if the user isn't authorized.

If the UI developer did their job correctly, the UI control is disabled or hidden, so the fact that this default value was returned doesn't really matter, because the user won't see it anyway. The important thing is that the app doesn't crash even though the UI developer did the right thing.

Now if the UI developer doesn't do their job, so the user can still see the control or returned value - at least the user won't see any real data, because GetProperty() returns this default value rather than the real value. So even if the UI developer messes up, the integrity of the application isn't compromised.

You should know that SetProperty() does throw an exception. This is because in all current data binding technologies, assuming the UI developer does their job by setting the control to readonly or disabling the control, there's never a case where SetProperty() should be called when the user isn't authorized. So throwing an exception in SetProperty() doesn't crash the app unless the UI developer fails to do their job.

Copyright (c) Marimer LLC