Csla 3.5 GetProperty and Authorisation

Csla 3.5 GetProperty and Authorisation

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


Skafa posted on Thursday, January 17, 2008

Hey Rocky,

I'm currently looking into and testing Csla 3.5 and I find the following quite awkward:

For retrieving a managed property's value you use: GetProperty<Type>(PropertyInfo)

this will fire (from the base) CanRead and things like that.

But how do we retrieve the fields raw value without firing authorisation code (for use in the Insert / Update DataPortal functions)?

When I look at the ProjectTracker code, you use the GetProperty method in the DataPortal functions. But won't this give weird resulsts when a certain property has authorisation rules and you still want to be able to save your object?

RockfordLhotka replied on Thursday, January 17, 2008

Hah! Good point. This is exactly why there are SetProperty() and LoadProperty() methods. Somehow it didn't occur to me that I need a ReadProperty() that works like LoadProperty().

(unless you can think of a better name than ReadProperty())

Skafa replied on Thursday, January 17, 2008

ReadProperty sounds fine for me.

great work so far; I'm happily using these new features.


vdhant replied on Thursday, January 17, 2008

This is what i was kinda getting to here. I should have put that i was specifically meaning 3.5.
http://forums.lhotka.net/forums/thread/20461.aspx

Sounds like a good plan and the name is good.
Anthony

Skafa replied on Friday, January 18, 2008

Rocky,

What version (cs or vb) is the most up to date? which do you recommend to use for testing at the moment ?

skagen00 replied on Friday, January 18, 2008

This would be of interest to me too, our architecture is going to use a couple of the features in 3.5 that we were just starting to build in now and are very interested in moving forward. (We use C#)

Also, in your release notes you say that the property stuff is prototype code and mentioned evaluating "if I like it". That is, how confident are you that this property approach will become a permanent part of CSLA? I assume extremely likely, but I wanted to get some sort of "yeah, that's the plan" if that's indeed the case. Would hate to start architecting around a 50/50 proposition :).

Chris

 

RockfordLhotka replied on Friday, January 18, 2008

I need to update the change log to remove the "prototype" comment. This is a done deal at this point - what you see is what you get (plus a ReadProperty() method as discussed earlier in the thread).

The VB and C# versions are in sync now, except that C# has indexed LINQ support and VB doesn't yet. Everything else should be the same. And if it isn't please let me know, as that means I missed something!

I'll probably do another preview release in the next 1-2 days, as I did get one of my other primary goals done, and I'd like feedback - the object-level authorization concept has now been formalized into Csla.Security. So instead of implementing (by convention) those four static methods on each type (CanGetObject(), etc), it is all managed now through CSLA itself.

This is an important change, as it allows the data portal and UI code to check authorization in a standard, reusable manner. The result is less code in each object (no need to check authorization in factory methods or a Save() override) and the potential to use authorization in UI frameworks.

Skafa replied on Friday, January 18, 2008

,,So instead of implementing (by convention) those four static methods on each type (CanGetObject(), etc), it is all managed now through CSLA itself.''

Can you give a quick example of how to implement this the 3.5 way?

KKoteles replied on Friday, January 18, 2008

Rocky,

I haven't started looking at 3.5 yet; however...  I know I've always had an issue with the use of ValidationRules.CheckRules() when I also had set AllowRead authorization on a property that also has business rules associated with it.  It would always error since users in a certain role couldn't access the property and the CheckRules() function would try to access the property on their behalf.

Is ValidationRules.CheckRules() going to be able to take advantage of the new ReadProperty() method to elimitate this problem?

Ken

RockfordLhotka replied on Friday, January 18, 2008

It depends on how you implement your rule method (as it did in 2.0-3.0).

 

If your rule method accesses the value through the public property on the business object, then GetProperty() will be called and authorization will occur.

 

If you want to avoid that pre-3.5 you needed to bypass the property and get the field directly. That’s true in 3.5 as well, except now you need to bypass the property and call ReadProperty() to get the “field” value.

 

So in this regard nothing has really changed in any meaningful way.

 

Rocky

 

 

From: KKoteles [mailto:cslanet@lhotka.net]
Sent: Friday, January 18, 2008 11:13 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Csla 3.5 GetProperty and Authorisation

 

Rocky,

I haven't started looking at 3.5 yet; however...  I know I've always had an issue with the use of ValidationRules.CheckRules() when I also had set AllowRead authorization on a property that also has business rules associated with it.  It would always error since users in a certain role couldn't access the property and the CheckRules() function would try to access the property on their behalf.

Is ValidationRules.CheckRules() going to be able to take advantage of the new ReadProperty() method to elimitate this problem?

Ken



KKoteles replied on Thursday, January 24, 2008

Rocky,

What I was trying to get at are things like your CommonRules.  As an example StringMaxLength uses reflection to call the getter of a property.  If you are not in a role that can 'see' a dependant property (however, for some reason it has a dependancy associated with a property you can 'see' - ValidationRules.AddDependantProperty) then everything is OK for the actual property being changed, but when the common rule fires for the denied read dependant property - you get an error (due to the deny read).

Can the common rules be updated to make sure they call the ReadProperty() methods?  This should eliminate the error when I am not reading the property directly, but the common rule functionality does for validation purposes.

Ken

RockfordLhotka replied on Thursday, January 24, 2008

Ahh, I see.

 

That’s a tricky problem. I’m not requiring that people use the new managed property scheme – nor do I want to. The managed property scheme is very nice, but does incur a performance hit when compared to using private fields. My guess is that for most apps the perf hit is acceptable, but for other apps it may not be acceptable.

 

So ReadProperty() and LoadProperty() aren’t universally useful. They only work with managed properties, not private field properties.

 

Rocky

 

 

From: KKoteles [mailto:cslanet@lhotka.net]
Sent: Thursday, January 24, 2008 2:24 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Csla 3.5 GetProperty and Authorisation

 

Rocky,

What I was trying to get at are things like your CommonRules.  As an example StringMaxLength uses reflection to call the getter of a property.  If you are not in a role that can 'see' a dependant property (however, for some reason it has a dependancy associated with a property you can 'see' - ValidationRules.AddDependantProperty) then everything is OK for the actual property being changed, but when the common rule fires for the denied read dependant property - you get an error (due to the deny read).

Can the common rules be updated to make sure they call the ReadProperty() methods?  This should eliminate the error when I am not reading the property directly, but the common rule functionality does for validation purposes.

Ken



vdhant replied on Thursday, January 24, 2008

I was thinking about this very problem and the solution I was thinking of is as follows.

As ReadProperty (read is all you would need for the validation) is a protected method this is what causes the issue. For example, if it where public it wouldn't be a problem but making it public is obviously something you don’t want to do.

Not that i have tested that this would work (i.e. whether the compiler will let you but i am thinking it should), why don’t you make ReadProperty 'internal protected' instead of just protected. This way any part of the internal framework (i.e. CSLA) can read a value when required. By doing this it would allow you to create a protected method within the base class for rule, that allows the code that makes up the rule call this method (passing in the property name that you need) which internal calls the ReadProperty. This would work (I think) because it is the base class (which is internal) is calling the ReadProperty (which is also internal). All that would have to occur is for the rule base class method, when it is called check that the target object the correct CSLA object and then pass on the request.

This is just what i was thinking for my 2 bob worth.
Thanks
Anthony

RockfordLhotka replied on Friday, January 25, 2008

That would work for managed fields, but not for private fields, because the rule method has no access to the private fields of an object.

 

Rocky

 

 

From: vdhant [mailto:cslanet@lhotka.net]
Sent: Thursday, January 24, 2008 9:11 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: Csla 3.5 GetProperty and Authorisation

 

I was thinking about this very problem and the solution I was thinking of is as follows.

As ReadProperty (read is all you would need for the validation) is a protected method this is what causes the issue. For example, if it where public it wouldn't be a problem but making it public is obviously something you don’t want to do.

Not that i have tested that this would work (i.e. whether the compiler will let you but i am thinking it should), why don’t you make ReadProperty 'internal protected' instead of just protected. This way any part of the internal framework (i.e. CSLA) can read a value when required. By doing this it would allow you to create a protected method within the base class for rule, that allows the code that makes up the rule call this method (passing in the property name that you need) which internal calls the ReadProperty. This would work (I think) because it is the base class (which is internal) is calling the ReadProperty (which is also internal). All that would have to occur is for the rule base class method, when it is called check that the target object the correct CSLA object and then pass on the request.

This is just what i was thinking for my 2 bob worth.
Thanks
Anthony



Copyright (c) Marimer LLC