[
https://issues.apache.org/jira/browse/QPIDJMS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPIDJMS-63.
-----------------------------------
Resolution: Fixed
Fix Version/s: 0.3.0
Thanks for finding+fixing this Jakub.
It is less clear the client is actually doing anything wrong in this case than
it was for QPIDJMS-33, but if the change gets things working I'm happy to go
with it. I did put back verification of the behaviour in the test peer. Upon
looking, this will give essentially the same behaviour that results from the
other JMS clients we have (they also seem to skip the initial response, but are
able to respond with an empty response if a subsequent empty challenge arrives,
which it does from the C++ broker but not the Java broker).
(Aside: The SASL EXTERNAL definition is fairly clear on what it means to send
the empty (but present) initial response and what happens when you dont,
whereas the ANONYMOUS definition is less so. The initial response is described
as trace information the client "may" send, and the exchange is described as a
single message from client to server, with note that protocols like AMQP 1.0
that allow inclusion of the initial response up front will be able to avoid a
roundtrip for the initial response.)
> SASL ANONYMOUS doesn't seem to work against the C++ broker
> ----------------------------------------------------------
>
> Key: QPIDJMS-63
> URL: https://issues.apache.org/jira/browse/QPIDJMS-63
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.2.0
> Reporter: Jakub Scholz
> Priority: Minor
> Fix For: 0.3.0
>
> Attachments: QPIDJMS-63.patch
>
>
> It looks like the same problem which was described and fixed for SASL
> EXTERNAL in QPIDJMS-33 is present also for the ANONYMOUS mechanism (broker
> log):
> {code}
> 2015-06-01 21:01:59 [Network] info Set TCP_NODELAY on connection to
> 192.168.1.241:57519
> 2015-06-01 21:01:59 [Broker] info Using AMQP 1.0 (with SASL layer)
> 2015-06-01 21:01:59 [Security] info SASL: Mechanism list: ANONYMOUS
> 2015-06-01 21:01:59 [Protocol] debug
> qpid.172.17.0.15:5672-192.168.1.241:57519 Sent SASL-MECHANISMS(ANONYMOUS) 31
> 2015-06-01 21:01:59 [Protocol] debug
> qpid.172.17.0.15:5672-192.168.1.241:57519 writing protocol header: 1-0
> 2015-06-01 21:01:59 [Protocol] debug
> qpid.172.17.0.15:5672-192.168.1.241:57519 Received SASL-INIT(ANONYMOUS, )
> 2015-06-01 21:01:59 [Security] info SASL: Starting authentication with
> mechanism: ANONYMOUS
> 2015-06-01 21:01:59 [Protocol] debug
> qpid.172.17.0.15:5672-192.168.1.241:57519 Sent SASL-CHALLENGE() 22
> 2015-06-01 21:01:59 [Security] info qpid.172.17.0.15:5672-192.168.1.241:57519
> Challenge issued
> 2015-06-01 21:02:09 [System] error Connection
> qpid.172.17.0.15:5672-192.168.1.241:57519 No protocol received after 10s,
> closing
> 2015-06-01 21:02:09 [Security] info qpid.172.17.0.15:5672-192.168.1.241:57519
> Connection closed prior to authentication completing
> 2015-06-01 21:02:09 [Security] info qpid.172.17.0.15:5672-192.168.1.241:57519
> Connection closed prior to authentication completing
> {code}
> This occurs only when the authentication is enabled in the AMQP broker. When
> the broker is started without authentication (--auth=no option) it actually
> works fine. Only when the ANONYMOUS mechanism is enabled as a part of the
> regular authentication, this error appears.
> The solution seems to be the same as in QPIDJMS-33. I.e. setting the initial
> response to EMPTY instead of null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
