activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1872) Correctly check for queue exists before creating shared queue
Date Thu, 31 May 2018 23:17:00 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16497309#comment-16497309
] 

ASF subversion and git services commented on ARTEMIS-1872:
----------------------------------------------------------

Commit 04d3ef894fd59a6f32904be27fc2464584102640 in activemq-artemis's branch refs/heads/2.6.x
from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=04d3ef8 ]

ARTEMIS-1872 fix examples broken after authn change

(cherry picked from commit b97bf8fac48e662fa9a69f484dc57e86da99cbc1)


> 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, 2.6.0
>            Reporter: Michael Andre Pearce
>            Priority: Major
>             Fix For: 2.7.0, 2.6.1
>
>
> 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)

Mime
View raw message