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

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

Github user michaelandrepearce commented on a diff in the pull request:

    https://github.com/apache/activemq-artemis/pull/2093#discussion_r189874889
  
    --- Diff: 
artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/SimpleString.java
 ---
    @@ -150,6 +150,10 @@ public CharSequence subSequence(final int start, final 
int end) {
           return subSeq(start, end);
        }
     
    +   public static boolean compare(SimpleString s1, SimpleString s2) {
    --- End diff --
    
    Good point, this isn't even needed, changed to using 
java.util.Objects.equals


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

Reply via email to