activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1872) Correctly check for queue exists before creating shared queue
Date Wed, 23 May 2018 13:37:00 GMT

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

ASF GitHub Bot commented on ARTEMIS-1872:
-----------------------------------------

Github user clebertsuconic commented on the issue:

    https://github.com/apache/activemq-artemis/pull/2093
  
    @michaelandrepearce Maybe I'm being slow.. but why do you need to check for version here?
    
    shouldn't this be a simple fix on checking the address before?
    
    
    from what I udnerstood from the fix is that you always remove the queue when creating
a shared subscription?


> 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)

Mime
View raw message