Does any body have interactions between the validation system and the security system?
When a property is secured with authorization rules and the current user does not have an authorized role, then that property can’t be validated, so if its object has a validation rule for that property the application can’t do its validations and it crash.
How do you solve this issue?
Thanks in advance
Benjamin
Just another thought on the subject. Even if you use
backing fields for validation, you still have a problem. For example, if
the field is required, but the user has not rights to fill it in, then that
user cannot save the object. So, you probably want to define a custom
rule for this situation that can pay attention to user rights or re-think your
design and maybe make entire object read-only for users who have no rights to
satisfy all the rules.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Monday, October 20, 2008 8:27 AM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] Interactions between Validation and Security
Systems
Usually the validation rules run the check directly against
the value in the field, or if you're using managed fields in 3.5 or higher, by
using ReadProperty instead of GetProperty.
HTH
Andy
Thanks to both.
I must study CSLA 3.5.
In our current version, 3.0.2, Validation rules read the value of the object's properties throug Reflection so the security checks are enabled. Our custom validations works the same way so we have this problem.
Reading fields directly is not a solution for us because some properties are calculated at runtime so they have no field associated.
Migrate to version 3.5 in short time is not possible for us because of we need to also change the NET framework (we use version 2). So we need a workaround to solve it until we can migrate everything.
Thanks again.
Benjamin
We use reflection for common validation rules. We have implemented one friend function for each property accessor following this pattern:
Public Overridable Property CustomerID() As System.String
Get
CanReadProperty("CustomerID", True)
Return get__CustomerID()
End Get
Set(ByVal Value As System.String)
CanWriteProperty("CustomerID", True)
set__CustomerID(Value)
End Set
End Property
Friend Overridable Function get__CustomerID() As System.String
If mCustomerID Is Nothing Then
Return ""
Else
Return obj
End If
End Function
Friend Overridable Sub set__CustomerID(ByVal Value As System.String)
If mCustomerID <> Value Then
mCustomerID = Value
PropertyHasChanged("CustomerID")
End If
End Sub
In our common validation rules we get the property value by this way:
Dim method As MethodInfo
method = target.GetType().GetMethod("get__" & e.PropertyName, _
BindingFlags.Instance _
Or BindingFlags.NonPublic _
Or BindingFlags.FlattenHierarchy)
If method IsNot Nothing Then
value = CStr(method.Invoke(target, Nothing))
Else
value = CStr(CallByName(target, e.PropertyName, CallType.Get))
End If
Notice that our common rules are located in a different package than the business logic, so we need to access friend functions through Reflection.
Thanks for your tip about throwing exceptions in our getter accessors. I didn’t know it. We’ll change it as soon as possible. We currently are using the old approach.
Many thanks for your help. This forum is great thanks to all of you (including Rocky, of course).
We are currently working with VS2005. We are goging to change to VS2008 as soon as we can. I supose it is what you mean we need. Isn't it?
Thanks Jonny
Benjamin
Copyright (c) Marimer LLC