ReadWriteAuthorization and control properties text and visible bound

SoftwareArchitect posted on Tuesday, May 30, 2006

I have a User object that has Username and Password property procedures.  If the username is the fixed app user (like 'administrator'), then the Username property cannot be modified.  I do this with a custom authorization rule where I set a DenyWrite rule (I deny all writes if the username is that special name).

The username property should be able to be read in any event; however, there are times when the username textbox should be hidden.  So, I created a UsernameVisible property in my object and I return true/false from that based on some business rules.

Here is the glitch....I bind my txtUsername.Text property to the business object's UserName property.  I then bind my txtUsername.Visible property to the object's UsernameVisible property.

The ReadWriteAuthorization loops through the bindings of the textbox, and first uses the value of the CanWrite("Username") to set the ReadOnly property of the control..which is perfect; however, it then uses the CanWrite("UsernameVisible") result to set the ReadOnly property (which always is true).

 So, the txtUsername control is ALWAYS enabled because all users can read the UsernameVisible property.  If I remove the databind to Visible the enabled/disabled works ok.  But I still would like to have the logic to show/hide the control in the business object and not in the front end.

Any ideas?  Questions?

Thanks,
Mike

xal replied on Tuesday, May 30, 2006

Sounds like you're mixing UI with busines logic.

The UsernameVisible property is not part of your business object data and shouldn't be exposed as such. It's actually some kind of a rule. An authorization rule that applies to username.
So, if anything you should deny reading (through authorization rules) to whoever in that specific scenario.
Or you can hold that UserNameVisible private to your object and do something like:

Public Property UserName() as string
Get
If UserNameVisible then
    Return mUserName
Else
    Return String.Empty
End If

End Get
...
End Property


(Of course, with all the security stuff I ommited).

Andrés

SoftwareArchitect replied on Thursday, June 01, 2006

Thanks for the response but I am still missing something...I may not have explained the situation correctly...

This is really modifying the business object to control the presentation behavior and perhaps I shouldn't even attempt to do so...

The problem is, that the state of the business object determines the authorization rule.  The object is an application settings object.  If the securitymode (property read from the db) equal 3, then the username textbox should not be shown (the username property in this case is NEVER allowed to be changed).  If the securitymode = 2 then it should be shown but since it is read only it will be disabled.

I hope that makes more sense.  Basically when authorization rules are applied, the object has no state so I am trying to work out how the business object can control (or should it?) the presentation of the username.

Thanks,
Mike

hurcane replied on Thursday, June 01, 2006

This is a question that can spark endless debate. I think the business object should make available the information necessary to support the UI. The business object should also work without a UI.

Do your security modes exist only for the UI? Are they interpreted by the business logic in any other ways? Is there going to be a security mode 1 or 4 in the future?

You could expose the SecurityMode property and write code on the form to set the properties of the control without using data binding. This is simple, but will cause problems if the meaning of SecurityMode will change in the future. If the meaning of SecurityMode is never going to change, then this is probably the simplest implementation.

The other option is to expose Enabled and Visible properties on the business object. Each property translates the SecurityMode. This is also fairly simple. If the meaning of SecurityMode is going to change in the future, you would not have to edit the UI (in theory) when the meaning changes.

Neither of these options is right or wrong. You have to decide which is the "best fit" for your situation.