Barney,
Barney Boisvert wrote:
>With the implementation as is, UnanimousBased doesn't allow voters to
>"screw up" by voting affirmatively if they'd approve some of the
>config attributes but deny others. Since they come in one at a time,
>any denials will guaranteed to result in an overall denial. It's not
>much of a difference, but if "unanimous" means "every voter approved
>(or abstained) on every attribute", then it's mindless processing that
>the voter's don't need to deal with. Of course, if the definition of
>unanimous is different (such as "every voter must approve at least one
>attribute") then that processing is no longer assured appropriate.
>
>
I have a different (potentially incorrect) use for multiple attributes.
I have an authorization question that requires more than one piece of
information to describe. For instance, one attribute names the action
being performed and a second (optional) attribute describes the context
in which the action is taking place.
In such use, the config attributes are not separable, serializable, etc.
- they have to be considered as an ordered list in performing the
authorizaiton check.
>RoleVoter would also have to be changed if UnanimousBased changed.
>Currently it defaults to DENIED and votes GRANTED as soon as it likes
>one of the attributes. If UnanimousBased passed all config
>attributes, it'd have to do the reverse, but that would make it
>incompatible with ConsensusBased and AffirmativeBased.
>
>In reality, I think it's ConsensusBased and AffirmativeBased that
>should change, so that all config attributes are treated individually,
>rather than OR-ed together for these two, and AND-ed for
>UnanimousBased. OR-ing seems "weird" to me, and was rather confusing
>when I started my first (and only) Acegi project; AND-ing makes a lot
>more sense, at least to me.
>
>
If your suggestion is followed, I would encourage to change the vote()
method to accept ConfigAttribute argument instead of an entire
ConfigAttributeDefinition, because under the proposed scenario a voter
would never be able to consider more than one attribute.
Going back to your question as to what Unanimous means ("every voter
must approve at least one attribute" or "every voter must approve every
attribute") - I read it "as every voter must approve given attribute
configuration". From the current API the decision managers are
responsible for combining outputs of the voters, and voters are
responsible for casting votes based on all available info (that's my
read anyhow - please correct me if the intent was different). In your
proposal (and, as you point out, in the current implementation of
RoleVoter) the decision manager is responsible for both: the logic of
combining voters, and the logic of combining config attributes.
cheers,
-peter.
>On 9/25/06, Ben Alex <[EMAIL PROTECTED]> wrote:
>
>
>>Peter Kharchenko wrote:
>>
>>
>>
>>>So if I wanted to make use of a voter that needs more than one config
>>>attribute at the same time, would you recommend writing an alternate
>>>version of UnanimousBased decision manager, or is there a reason why
>>>Unanimous decision have to be done this way (and therefore I need to
>>>switch to AffermativeBase or something else) ?
>>>
>>>
>>It's pretty rare to use UnanimousBased. Most people find
>>AffirmativeBased the most useful AccessDecisionManager.
>>
>>I honestly can't remember why UnanimousBased was designed this way. It
>>was like this in the initial commit, so goes right back to March 2004
>>(if not late 2003 when I first wrote it). A good lesson why I should
>>have JavaDoced "why".
>>
>>Given I cannot see any strong justification for this behavior, I am not
>>opposed to modifying it to be consistent with ConsensusBased. The
>>UnanimousBased approach is basically a ConsensusBased approach, except
>>if any AccessDecisionVoter denies, then immediately throw
>>AccessDeniedException.
>>
>>I would want to wait until 1.1.0 before changing anything, though, in
>>case someone relies on UnanimousBased's current logic. Please feel free
>>to raise a JIRA issue if you wish.
>>
>>Cheers
>>Ben
>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>_______________________________________________
>>Home: http://acegisecurity.org
>>Acegisecurity-developer mailing list
>>Acegisecurity-developer@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
>>
>>
>>
>
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
