qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mansion <ja...@mansionfamily.plus.com>
Subject Re: Problem running tests/client_test
Date Tue, 17 Mar 2009 19:48:23 GMT
Steve Huston wrote:
> Fix is on svn trunk...
> -Steve
How did you test it?  It didn't work for me using the rather minimal
debug settings in the test_client solution.

My analysis of the failure is:

In WindowsSasl, if we have PLAIN on offer, then we choose it - even if we
do not have a configured username and password.  Also, we seem to take no
notice of settings.mechanism.

This will fix it so that the client can connect in the absence of a 
though it still ignores the mechanism.  Arguably, more information is needed
in the case where we have a username but the password is empty - perhaps we
infer the username from the current login session but have not been 
given the
password - should we use PLAIN and hope that an empty password is valid, or
still use ANONYMOUS in that case because we don't know whether 'empty' means
'password not provided' ie incomplete information.  I think we would need a
flag in the settings structure to handle this (or, we should never infer the
user name and require that user name and password are both provided - I find
user name inference handy though).

C:\src\qpid\trunk\qpid\cpp\src>svn diff qpid\client
Index: qpid/client/windows/SaslFactory.cpp
--- qpid/client/windows/SaslFactory.cpp (revision 755031)
+++ qpid/client/windows/SaslFactory.cpp (working copy)
@@ -110,7 +110,7 @@
         throw InternalErrorException(QPID_MSG("Sasl error: no common 

     std::string resp = "";
-    if (havePlain) {
+    if (havePlain && !settings.username.empty()) {
         mechanism = PLAIN;
         resp = ((char)0) + settings.username + ((char)0) + 

Also ...

The WindowsSasl implementation doesn't do anything Windows-ish.  Why isn't
this basic implementation the default if CyrusSasl is not available?  Is it
intended that a Windows security token could be passed?  This makes sense
for Windows deployments, but might also be workable for non-Windows brokers
that have access to a domain controller.  If you can support single signon
for Windows client applications, there will be general rejoicing.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message