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.
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. cheers, barneyb 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
