Hi,
So the standard IsInRole stuff seems pretty obvious. But is it possible to have two authorization rules, and both must pass? I'd like to combine an IsInRole test with a test of the Targets state (if the object is not in a certain state, most properties must become read-only. Otherwise, all properties can be changed.
It looks like though when getting the auth rules, a FirstOrDefault rules out this scenario.
Would the correct path be to create a rule which does both checks in one Execute?
Thanks
Andy
Hi Andy,
Sure you can. Add as many separate rules as you want.. It works as you said: all rules must pass in order for the user to have authorization. The point is to "modularize": each rule is a module and you combine modules differently according to your needs.
Well the reason I posted the question is because looking at the code for CanWriteProperty, if fiters things to a list of rules which apply to writing the property, then does a FirstOrDefault. So that looks to me like while I can add as many as I want, only one will actually get run... unless I have a "master rule" or can use chaining.
So, either I'm reading the code wrong, in which case I'll add multiples, or only one in fact will be run, in which case I'd like to know what's considered "best practice."
Thanks!
Andy
There can be only one authz rule per element per action. So only one rule for property read, one for property write, etc.
I could have tried to allow multiple rules - but then there'd be the whole question of whether they should be AND or OR or whatever. And this particular stuff is pretty performance sensitive, since the authz rules get run a lot.
So I kept things simple - one rule per.
That means if you want something more complex than IsInRole or IsNotInRole you need to write a rule. But writing a rule is just not hard - so I don't see that as much of a barrier either.
Hi Rocky,
In fact that's what I've done in my tests: one rule per element per action. I agree the performance is paramount.
I was mxing it up with business rules where you can add several business rules to the same property. If the behaviour is so different, there is no point in using the same class. Or is it?
As a side note, I confirmed my VS2010 (is completely nuts).
When I look at my
BusinessRules.AddRule();
I find it hard to understand because the same apparent code points to 2 different places (it's also coloured differently).
When adding a business rule (those that inherit from BusinessRule), BusinessRules refers to a protected property of Csla.Core.BusinessBase (!!!)
When adding a business authorization rule (those that inherit from AuthorizationRule), BusinessRules refers to a class of Csla.Rules
in both cases AddRule is a method of Csla.Rules.BusinessRules.
It isn't that Visual Studio is nuts, it is that there are two ways to use Csla.Rules.BusinessRules.
BusinessBase does expose a protected property named BusinessRules that refers to an instance of BusinessRules, which is responsible for managing most of the business rules behaviors.
However, there are also some static methods on Csla.Core.BusinessRules itself that are used to associate per-type authorization rules with a type. This is what you are invoking within the AddObjectAuthorizationRules() method - it has to be this way because no instance of any object can be created to find out if the user is even authorized to create an instance of the object.
This is really no different from 3.x, which had the same concept with the Csla.Security.AuthorizationRules class.
Copyright (c) Marimer LLC