[
https://issues.apache.org/jira/browse/QPID-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15399801#comment-15399801
]
Rob Godfrey commented on QPID-7318:
-----------------------------------
h4. Patch 3
{quote}
* The refactoring from AbstractAMQPConnection#isAuthorizedMessagePrincipal to
AbstractAMQPConnection#checkAuthorizedMessagePrincipal changed behaviour. e.g,
in the case where userId = null; authPrincipal = "";
{quote}
Yes - the old code was wrong. The intention of the code is to validate that
the userId carried by the message equals the currently authenticated user. The
old code said that if the message was not labelled with a user id, this was
only valid if the sender was authenticated as the user with "" as its name.
This is nuts. The correct way to treat a message which does not claim to be
sent by any particular user is to say "there is no need to validate"... which
is what the new code does :-)
{quote}
* I am surprised the while-loop in CachingSecurityToken#authoriseMethod
terminates. I would have thought that cache contains a reference to the current
AccessControlCache instance. calls to CACHE_UPDATE.compareAndSet will (if
anything) change the _cache reference but leave the local cache reference
untouched. So why would the while-loop ever terminate? I would expect it to
look something like this
AccessControlCache cache;
{quote}
Yep - fixed.
{quote}
* comment in LegacyAccessControlAdapter#authorise seems out of place
{quote}
Yeah - the comment and code section were copied verbatim from their old
location in SecurityManager... but obviously bears no relation to what is going
on.
> [Java Broker] Refactor existing ACL plugin code
> -----------------------------------------------
>
> Key: QPID-7318
> URL: https://issues.apache.org/jira/browse/QPID-7318
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> While the aim is to redesign the ACL implementation in the v6.2 or v7.0
> timeframe, there is still utility in tidying up the existing ACL
> implementation a bit. In particular by separating out functions and
> providing a better encapsulation, we will make the job of writing automated
> upgraders to any new ACL implementation substantially easier.
> As a first step we can separate out the parsing of the ACL file, from the
> "rule based" implementation of ACLs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
