activemq-issues mailing list archives

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


ASF GitHub Bot commented on ARTEMIS-1872:

Github user clebertsuconic commented on the issue:
    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
    It seems we can simplify this a lot?

> Correctly check for queue exists before creating shared queue
> -------------------------------------------------------------
>                 Key: ARTEMIS-1872
>                 URL:
>             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
> securityCheck(address, name, durable ? CheckType.*_CREATE_DURABLE_QUEUE_* : CheckType.*_CREATE_NON_DURABLE_QUEUE_*,
> 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

View raw message