[
https://issues.apache.org/jira/browse/ARTEMIS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487282#comment-16487282
]
ASF GitHub Bot commented on ARTEMIS-1872:
-----------------------------------------
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2093
the more I digg.. the more I'm convinced there's no need for the version
check... if we can speak on IRC before we merge this?
The version check was basically for wire compatibility... for semantic you
just change the server... there's no wire changes here. .just keep it this way?
and if this is breaking the client->server contract in a way it needs a
raise to the properties. .this would bump the release into 2.7.0...
We can't make changes to versioning on point releases... if later on we
need to make any other changes into 2.7.0... it will be some extra complexity
on bumping the release there again.
It seems we can simplify this a lot?
> Correctly check for queue exists before creating shared queue
> -------------------------------------------------------------
>
> Key: ARTEMIS-1872
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1872
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.5.0
> Reporter: Michael Andre Pearce
> Priority: Major
>
> Prior to 2.5.0, artemis incorrectly always checked the perms for Non Durable
> on createSharedQueue , even if the queue being created was a Durable queue.
> securityCheck(address, name, CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*);
>
> In 2.5.0+ this has been corrected, so it checks the permissions appropriately
> for the durability.
> securityCheck(address, name, durable ? CheckType.*_CREATE_DURABLE_QUEUE_* :
> CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*);
>
> This though has exposed that in some area's of the Core client code, and also
> AMQP, and OpenWire that the code isn't checking that queue exists before
> calling to create it, meaning a client with consume permission but without
> create durable queue permissions, would fail but should not as the queue
> exists.
> Also it was noted on creating the test case to prove this that AMQP JMS
> Client when security exception occurs, was not correctly throwing
> JMSSecurityException, this is due to the broker not returning the correct
> AMQP error code, in these circumstances.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
