[
https://issues.apache.org/jira/browse/DISPATCH-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090518#comment-16090518
]
Jakub Scholz commented on DISPATCH-737:
---------------------------------------
Hi Ganesh,
I played with it bit more and I think I fixed my problems as part of it. So I
created a PR. I hope you don't mind. I actually tested it only on my `qdstat`
use cases, so I hope it doesn't break anything else.
I identified two problems:
* The username and password are not used to decide whether to use SASL or not
if they are directly part of the URL
* If the SASL mechanism is not specified, the code does str(None) - this is
interpreted by the BlockingConnection as "do not use any SASL mechs" and
results in this error: _ConnectionException: Connection
amqp://admin:123456@localhost:32776/$management disconnected:
Condition('amqp:unauthorized-access', 'Authentication failed [mech=none]')_. So
if sasl.mechs is None, we should simply pass None to BlockingConnection and
that will select the best suitable mech.
This seems to fix my issues.
JAkub
> qdstat and qdmanage always force sasl exchange
> ----------------------------------------------
>
> Key: DISPATCH-737
> URL: https://issues.apache.org/jira/browse/DISPATCH-737
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
> Affects Versions: 0.7.0
> Reporter: Ganesh Murthy
> Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> qdmanage and qdstat use the Proton Python blocking API to do its work. The
> Python API offers a flag called sasl_enabled and it is always set to true
> which always initiates a SASL exchange. SASL should only be invoked when
> mechanisms are explicitly provided by qdstat and qdmanage via its
> sasl-mechanisms or sasl-username or sasl-password or ssl parameters
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
