[
https://issues.apache.org/jira/browse/ARTEMIS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487722#comment-16487722
]
ASF subversion and git services commented on ARTEMIS-1872:
----------------------------------------------------------
Commit a9d9731f0a644ff5bf6fb65583f1fabc832d9ae5 in activemq-artemis's branch
refs/heads/master from [~michael.andre.pearce]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=a9d9731 ]
ARTEMIS-1872 Check for queue exists before creating shared queue
1. Add tests case to verify issue and fix, tests also tests for same behavior
using CORE, OPENWIRE and AMQP JMS Clients.
2. Update Core Client to check for queue before creating, sharedQueue as per
createQueue logic.
3. Update ServerSessionPacketHandler to handle packets from old clients to
perform to implement the same fix server side for older clients.
4. Correct AMQP protocol so correct error code is returned on security
exception so that amqp jms can correctly throw JMSsecurityException
5. Correct AMQP protocol to check for queue exists before create
6. Correct OpenWire protocol to check for address exists before create
> 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)
