Re: [Acegisecurity-developer] AccessDecisionVoter interface and multiple configuration attributes

2006-09-25 Thread Ben Alex
Peter Kharchenko wrote:

  I am writing a custom voter implementation and have a question 
 regarding how configuration attributes are being fed to the voters.

Hi Peter

Basically the AccessDecisionVoter.supports(ConfigAttribute attribute)
method is structured the way it is because we want
AbstractSecurityInterceptor to poll every possible voter and run-as
manager and after-invocation manager to see if somebody is able to
digest or process a particular ConfigAttribute.

At actual decision time, the AccessDecisionVoter.vote(Authentication
authentication, Object object, ConfigAttributeDefinition config) method
accepts the full ConfigAttributeDefinition because a voter might make
different decisions based on the presence of extra attributes on the
particular secure object invocation.

Hope this helps clarify the rationale.

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.phpp=sourceforgeCID=DEVDEV
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


Re: [Acegisecurity-developer] AccessDecisionVoter interface and multiple configuration attributes

2006-09-25 Thread Ben Alex
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.phpp=sourceforgeCID=DEVDEV
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer