Correct me if I'm wrong but there is no way to stop authorization rules on data portals being fired once they are coded into an object? By this I mean create, update etc.
This seems a bit restrictive on the developer. What about the scenario where an object needs to be loaded internally in another rule or object but the current user does not have permission to get that object. The object would never be exposed to the user but it is required for some other meaningful task.
I'm guessing there is a good reason for it? I'm just finding them a bit restrictive.
An example. I have a user object for manipulating a user. Permission are set to only Admin can create, edit etc. However the current logged in user also need to be able to update their own details. So it would have been nice just to create a simple method UpdateCurrentUser(args) where this method would load a User object for the current user and update the relevant properties and then save it. However this won't work due to authorization rules. I could I suppose create a new object from User and create a new set of rules however this seem overkill.
You may be able to use RuleSet to define separate rules (both business and authz) in a BO to fulfill your requirements.
For rules ( and reading data behind the scenes) - I'd prefer to use a command object (or readonly object).
A editable user object could define:
a) both read and write property rules so that only the current user i allowed to see/edit the fields.
b: An Authz rule for Save so that user is only allowed to save "self" user.
c: Allow both Admin and User to Fetch User object.
Another (completely) different approach is to use the UOW (unit-of-work) strategy. Authorization rules is only enforced automatically on the "root" object. With UOW you create separate "root" object for each use case to fetch/create children, lists for comboboxes etc and save its children. Each UOW object would have separate authorization rules.
A UOW patterm might work quite well. I already have a CurrentUser object for getting access to Idenity objects etc. So it would just be a simple case of converting that to a BusinessBase fetching the user as a Child (adding Child_Fetch methods) then updating the user as a child. I could expose only the relevant properties on the user. Enforcing the fetch to be the current UserID works quite nice too.
Still seems like a modest amount of work, this is only one example where simple the ability to override authorization at the dataportal level would be a nice option.
Hi,
Csla is designed to work on both client and web server apps. Authz rules for the static factory methods is registered per type (for all instances/root dataportal methods) and should NOT be changed, especially in a multi threaded Web application but also client applications are becoming more multi-threaded.
Another option is to register method and add separate Authz rule for factory methods.This way you will be able to inspect the properties of the fetched object in your Authz rule.
public static MethodInfo NewEditableRootMethod = RegisterMethod(typeof (Root), "NewEditableRoot"); public static Root NewEditableRoot() { var obj = DataPortal.Create<Root>(); obj.CanExecuteMethod(NewEditableRootMethod, true); return obj; }
It is important to remember that authorization rules (in CSLA 4) don't have to be role based. They are just a type of business rule, and they can use the state of the object, the state of the application, and the user prinicpal/identity information in any way they choose.
So you can create a rule that says I can edit the object if I am in the Admin role, or if my identity .Name property matches the Username property of the object (or something like that).
Hello Rocky:
Any sample of this?
Hi,
CslaGenFork has a rules sample project that includes authorization rules like
Have a look at http://cslagenfork.codeplex.com/
Hello Rocky:
Any sample of this?
Custom authorization rules are discussed in the 'Using CSLA 4' ebook series. I suspect they are also used in the rules tutorial sample, though I am traveling right now and can't confirm that.
Yes, there is some sample rules in the RuleTutorial sample.
The main difference between business rules and authorization rules is that
So while you may have many business rules executing in Priority order - there can only be 1 authorization rule.
If/when this limit hits you - consider override of the CanReadProperty/CanWriteProperty or CanExecuteMethod in your <bo>.
Copyright (c) Marimer LLC