With the introduction of the IsInRoleProvider capability in 3.5.1, I found I could map the CSLA read/write authorization rules to our internal mechanism.
The problem is that the "answer" to whether reading or writing is allowed is context dependent, even for the same user. So, a user may be able to read/write a property by proxy via another business object server side that they are not allowed to read or write directly client side.
However, the result is cached on the first read, so we can't implement our context dependency with the current mechanism.
If there was just some way my BusinessBase derived class could be allowed to answer the question "Should the cache be flushed", I could make this work.
This seems like a decent idea. The perf impact of turning it off may be non-trivial, but I guess that'd be a problem you could deal with :)
I'll add the idea to the wish list.
Thanks!
After I posted this, I discovered that I think my particular implementation could do what was needed by overriding CanReadProperty() and CanWriteProperty().
In my case, I basically don't want to do any authorization checking on the server-side of the data portal. So, I just have these functions check the LogicalExecutionLocation and bypass the check if it's on the server. This is not a perfect solution, but I think it will work OK for what I need.
Copyright (c) Marimer LLC