You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2017/12/07 23:30:01 UTC

[jira] [Comment Edited] (ARTEMIS-1545) JMS MessageProducer fails to throw security exception on send when message is sent non-persistent, but not authorised

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

Timothy Bish edited comment on ARTEMIS-1545 at 12/7/17 11:29 PM:
-----------------------------------------------------------------

This doesn't actually strike me as being a bug on the send as many JMS provider will indeed send the message asynchronously and if any error is reported on send fail it'd be done via the JMS ExceptionListener on the Connection.  It would be nice if the createProducer failed here if not authorized to write to the target destination but if using an anonymous producer than again this seems to operate as many other JMS clients would.  

The standard practice here would be to use a transaction to create a sync point (i.e. the commit) where the broker would report the operation as failed if any of the sends inside that TX failed for some reason.  Since the NON_PERSISTENT delivery mode is 'at-most-once' you shouldn't expect the same QoS behaviors on the client send (unless of course you can configure that which appears you could via the block option). 


was (Author: tabish121):
This doesn't actually strike me as being a bug on the send as many JMS provider will indeed send the message asynchronously and if any error is reported on send fail it'd be done via the JMS ExceptionListener on the Connection.  It would be nice if the createProducer failed here if not authorized to write to the target destination but if using an anonymous producer than again this seems to operate as many other JMS clients would.  

The standard practice here would be to use a transaction to create a sync point (i.e. the commit) where the broker would report the operation as failed if any of the sends inside that TX failed for some reason.  Since the NON_PERSISTENT delivery mode is 'at-most-once' you shouldn't expect the same QoS behaviors on the client send (unless of course you can configure that in which appears you could via the block option). 

> JMS MessageProducer fails to throw security exception on send when message is sent non-persistent, but not authorised
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1545
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1545
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>            Reporter: Michael Andre Pearce
>
> When sending persistent, behaviour is as expected and a Security exception is thrown. The same behaviour should be expected when sending non-persistent, by default.
> This can be recreated easily by the following:
> Add the following security section , that means guest is not auth'd to send to "guest.cannot.send"
> activemq-artemis/tests/jms-tests/src/test/resources/broker.xml
>  <security-setting match="guest.cannot.send">
>                <permission type="createDurableQueue" roles="guest,def"/>
>                <permission type="deleteDurableQueue" roles="guest,def"/>
>                <permission type="createNonDurableQueue" roles="guest,def"/>
>                <permission type="deleteNonDurableQueue" roles="guest,def"/>
>                <permission type="consume" roles="guest,def"/>
>                <permission type="browse" roles="guest,def"/>
>                <permission type="send" roles="def"/>
>            </security-setting>
> Then add the following tests to this test (first is proving exception correctly is thrown when persistent is sent using jms api, and second shows behaviour difference and no error):
> activemq-artemis/tests/jms-tests/src/test/java/org/apache/activemq/artemis/jms/tests/SecurityTest.java
>   /**
>     * Login with valid user and password
>     * But try send to address not authorised - Persistent
>     * Should not allow and should throw exception
>     */
>    @Test
>    public void testLoginValidUserAndPasswordButNotAuthorisedToSend() throws Exception {
>       ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
>       Connection connection = connectionFactory.createConnection("guest", "guest");
>       Session session = connection.createSession();
>       Destination destination = session.createQueue("guest.cannot.send");
>       MessageProducer messageProducer = session.createProducer(destination);
>       try {
>          messageProducer.send(session.createTextMessage("hello"));
>          fail("JMSSecurityException expected as guest is not allowed to send");
>       } catch (JMSSecurityException activeMQSecurityException){
>          //pass
>       }
>       connection.close();
>    }
>    /**
>     * Login with valid user and password
>     * But try send to address not authorised - Non Persistent.
>     * Should have same behaviour as Persistent with exception on send.
>     */
>    @Test
>    public void testLoginValidUserAndPasswordButNotAuthorisedToSendNonPersistent() throws Exception {
>       ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
>       Connection connection = connectionFactory.createConnection("guest", "guest");
>       Session session = connection.createSession();
>       Destination destination = session.createQueue("guest.cannot.send");
>       MessageProducer messageProducer = session.createProducer(destination);
>       messageProducer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
>       try {
>          messageProducer.send(session.createTextMessage("hello"));
>          fail("JMSSecurityException expected as guest is not allowed to send");
>       } catch (JMSSecurityException activeMQSecurityException){
>          //pass
>       }
>       connection.close();
>    }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)