[
https://issues.apache.org/jira/browse/QPID-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17436829#comment-17436829
]
ASF GitHub Bot commented on QPID-8565:
--------------------------------------
alex-rufous commented on pull request #113:
URL: https://github.com/apache/qpid-broker-j/pull/113#issuecomment-956234276
> CONNECTION_LIMIT and CONNECTION_FREQUENCY_LIMIT properties are deprecated
and they are not supported.
That is not a precise statement. The support for CONNECTION_LIMIT and
CONNECTION_FREQUENCY_LIMIT had been dropped a while ago. I deleted it
completely as the warning was misleading. It was stating that the feature was
deprecated whilst in fact it was completely removed. The deprecated feature
should work as expected.
> Actual implementation silently parses and adds a new predicate. This is
the worst scenario because:
>
> 1. "CONNECTION_LIMIT" and "CONNECTION_FREQUENCY_LIMIT" are silently
parsed but the code does not perform expected check.
>
> 2. The rule itself becomes unmatchable because any object never has
the property "CONNECTION_LIMIT" or "CONNECTION_FREQUENCY_LIMIT". Hence, any
object can not match with the rule.
IMHO, handling CONNECTION_LIMIT and CONNECTION_FREQUENCY_LIMIT without
implementation did not look right to me.
Marec, are you planning to restore the behaviour behind CONNECTION_LIMIT and
CONNECTION_FREQUENCY_LIMIT ?
>
> The main aim of this changes is performance. Hence, I would like to keep
the chain of rule predicates as short as possible. The RulePredicate.Any does
not perform any check and so it can be omitted in the chain.
IMHO, check for "any" looked like a premature optimisation to me. Have you
tested a performance impact? I anticipate that performance impact from having
an extra predicate in chain should be neglectable. The code readability has
improved significantly without additional "any" check.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> [Broker-J] Enhancement of ACL rule predicates evaluation
> --------------------------------------------------------
>
> Key: QPID-8565
> URL: https://issues.apache.org/jira/browse/QPID-8565
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Marek Laca
> Priority: Minor
> Labels: Broker, Java
>
> The access control plugin checks the rights of the user to perform an action
> on the broker's component. The access control plugin iterates through the ACL
> rules and checks their predicates. The user action is denied or allowed based
> on the test result.
> The aim of this task are refactoring of the code that is required for the
> [QPID-8487|https://issues.apache.org/jira/browse/QPID-8487] and
> [QPID-8488|https://issues.apache.org/jira/browse/QPID-8488], improving the
> test of the ACL rule predicates and removing useless classes. Changes should
> not have any impact on the functionality of the access control plugin.
> The ObjectProperties class has two responsibilities, it holds the rule
> predicates and also the objects properties that are checked. The
> responsibilities of ObjectProperties class should be split because the code
> should honor the principle of one responsibility per class.
> The Rule class is treated as immutable but the immutability is not enforce by
> the code.
> The Action, AclAction and ClientAction classes are only data holders that
> don't have any real responsibility.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
