Re: Problem running tests/client_test
James Mansion wrote: The WindowsSasl implementation doesn't do anything Windows-ish. Why isn't this basic implementation the default if CyrusSasl is not available? There is code in the ConnectionHandler that is intended to cover the case where a specific SaslFactory is not available that does broadly the same thing. 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. Cyrus SASL does claim support for NTLM, though I have not tested that. I have tested GSSAPI. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Problem running tests/client_test
Hi James,
Could you please attach your patch to QPID-1733
(http://issues.apache.org/jira/browse/QPID-1733) - be sure to
attribute license to ASF.
Thanks,
-Steve
-Original Message-
From: James Mansion [mailto:ja...@mansionfamily.plus.com]
Sent: Tuesday, March 17, 2009 3:48 PM
To: dev@qpid.apache.org
Subject: Re: Problem running tests/client_test
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
username,
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\srcsvn 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
mechanism
));
std::string resp = ;
-if (havePlain) {
+if (havePlain !settings.username.empty()) {
mechanism = PLAIN;
resp = ((char)0) + settings.username + ((char)0) +
settings.password;
}
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.
James
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Problem running tests/client_test
Gordon Sim wrote: James Mansion wrote: The WindowsSasl implementation doesn't do anything Windows-ish. Why isn't this basic implementation the default if CyrusSasl is not available? There is code in the ConnectionHandler that is intended to cover the case where a specific SaslFactory is not available that does broadly the same thing. Isn't it cleaner to have it as a basic Sasl handler? This will need revisiting anyway won't it, since in 1.0 there will potentially be a TLS handler inserted in the codec chain ahead of the SaslHandler? I'm trying to get my head around the processing chain at the moment - is there a design doc anywhere? James - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Problem running tests/client_test
James Mansion wrote: Gordon Sim wrote: There is code in the ConnectionHandler that is intended to cover the case where a specific SaslFactory is not available that does broadly the same thing. Isn't it cleaner to have it as a basic Sasl handler? Yes, if you want to submit a patch for that I agree it would be an improvement. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Problem running tests/client_test
Hi James,
I tested it using one of the examples in cpp/examples - I did notice
that test_client didn't work, but had bigger fish to fry before
getting back to that.
You raise great points that I'd like to discuss more. I don't have
time at the moment, but wanted to ack your note. I'll reply further
another day.
-Steve
-Original Message-
From: James Mansion [mailto:ja...@mansionfamily.plus.com]
Sent: Tuesday, March 17, 2009 3:48 PM
To: dev@qpid.apache.org
Subject: Re: Problem running tests/client_test
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
username,
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\srcsvn 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
mechanism
));
std::string resp = ;
-if (havePlain) {
+if (havePlain !settings.username.empty()) {
mechanism = PLAIN;
resp = ((char)0) + settings.username + ((char)0) +
settings.password;
}
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.
James
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Problem running tests/client_test
Hi James,
This is a known issue: https://issues.apache.org/jira/browse/QPID-1733
I'm working on a fix for it.
Workaround is to start with broker with --auth no.
-Steve
--
Steve Huston, Riverace Corporation
Check out my networked programming blog at
http://stevehuston.wordpress.com/
-Original Message-
From: James Mansion [mailto:ja...@mansionfamily.plus.com]
Sent: Monday, March 16, 2009 4:32 PM
To: dev@qpid.apache.org
Subject: Problem running tests/client_test
I have tried to run client_test from cpp/src/tests.
The client is being rejected because it is trying to use an empty
mechanism and the server wants 'ANONYMOUS' or 'PLAIN'.
2009-mar-16 08:13:38 notice Broker running
2009-mar-16 08:14:18 debug RECV [127.0.0.1:1716] INIT(0-10)
2009-mar-16 08:14:18 info SASL: Mechanism list: ANONYMOUS PLAIN
2009-mar-16 08:14:18 trace SENT 127.0.0.1:1716 INIT(0-10)
2009-mar-16 08:14:18 trace SENT [127.0.0.1:1716]: Frame[BEbe;
channel=0;
{ConnectionStartBody:
server-properties={qpid.federation_tag:V2:36:str16(19f09716-99
45-47c0-a136-a2acdc056dd1)};
mechanisms=str16{V2:9:str16(ANONYMOUS), V2:5:str16(PLAIN)};
locales=str16{V2:5:str16(en_US)}; }]
2009-mar-16 08:14:18 trace RECV [127.0.0.1:1716]: Frame[BEbe;
channel=0;
{ConnectionStartOkBody:
client-properties={qpid.client_pid:F4:int32(7268),qpid.client_
ppid:F4:int32(0),qpid.client_process:V2:0:str16(),qpid.session
_flow:F4:int32(1)};
mechanism=; response=xx; locale=en_US; }]
2009-mar-16 08:14:18 info SASL: Starting authentication with
mechanism:
2009-mar-16 08:14:18 debug Exception constructed: Unsupported
mechanism
2009-mar-16 08:14:18 trace SENT [127.0.0.1:1716]: Frame[BEbe;
channel=0;
{ConnectionCloseBody: reply-code=320; reply-text=connection-forced:
Unsupported mechanism; }]
This is with the VS solutions pretty much as-is, client and server
on
the same XP box, modulo fixing the build issues with WinSDK 7
and Boost
1.38.
Looks clear-cut from the trace, but maybe its something I've done?
James
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Problem running tests/client_test
Fix is on svn trunk...
-Steve
-Original Message-
From: Steve Huston [mailto:shus...@riverace.com]
Sent: Monday, March 16, 2009 4:45 PM
To: 'dev@qpid.apache.org'
Subject: RE: Problem running tests/client_test
Hi James,
This is a known issue:
https://issues.apache.org/jira/browse/QPID-1733
I'm working on a fix for it.
Workaround is to start with broker with --auth no.
-Steve
--
Steve Huston, Riverace Corporation
Check out my networked programming blog at
http://stevehuston.wordpress.com/
-Original Message-
From: James Mansion [mailto:ja...@mansionfamily.plus.com]
Sent: Monday, March 16, 2009 4:32 PM
To: dev@qpid.apache.org
Subject: Problem running tests/client_test
I have tried to run client_test from cpp/src/tests.
The client is being rejected because it is trying to use an empty
mechanism and the server wants 'ANONYMOUS' or 'PLAIN'.
2009-mar-16 08:13:38 notice Broker running
2009-mar-16 08:14:18 debug RECV [127.0.0.1:1716] INIT(0-10)
2009-mar-16 08:14:18 info SASL: Mechanism list: ANONYMOUS PLAIN
2009-mar-16 08:14:18 trace SENT 127.0.0.1:1716 INIT(0-10)
2009-mar-16 08:14:18 trace SENT [127.0.0.1:1716]: Frame[BEbe;
channel=0;
{ConnectionStartBody:
server-properties={qpid.federation_tag:V2:36:str16(19f09716-99
45-47c0-a136-a2acdc056dd1)};
mechanisms=str16{V2:9:str16(ANONYMOUS), V2:5:str16(PLAIN)};
locales=str16{V2:5:str16(en_US)}; }]
2009-mar-16 08:14:18 trace RECV [127.0.0.1:1716]: Frame[BEbe;
channel=0;
{ConnectionStartOkBody:
client-properties={qpid.client_pid:F4:int32(7268),qpid.client_
ppid:F4:int32(0),qpid.client_process:V2:0:str16(),qpid.session
_flow:F4:int32(1)};
mechanism=; response=xx; locale=en_US; }]
2009-mar-16 08:14:18 info SASL: Starting authentication with
mechanism:
2009-mar-16 08:14:18 debug Exception constructed: Unsupported
mechanism
2009-mar-16 08:14:18 trace SENT [127.0.0.1:1716]: Frame[BEbe;
channel=0;
{ConnectionCloseBody: reply-code=320;
reply-text=connection-forced:
Unsupported mechanism; }]
This is with the VS solutions pretty much as-is, client and
server on
the same XP box, modulo fixing the build issues with WinSDK 7
and Boost
1.38.
Looks clear-cut from the trace, but maybe its something I've done?
James
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Problem running tests/client_test
Steve Huston wrote: Hi James, This is a known issue: https://issues.apache.org/jira/browse/QPID-1733 I'm working on a fix for it. Workaround is to start with broker with --auth no. OK, thanks. Perhaps teh JIRA organisation could be improved? - the Java tests have a JIRA section and I looked for one for C++ - and I looked in the C++ client since it seems that the empty response from the client is in error rather than the list from the broker. Is teher a release note I've failed to read with this sort of thing in it? James - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Problem running tests/client_test
You're right - the jira was mis-classified as a C++ broker issue when it was a C++ client issue. There's no jira classification for C++ tests. -Original Message- From: James Mansion [mailto:ja...@mansionfamily.plus.com] Sent: Monday, March 16, 2009 6:38 PM To: dev@qpid.apache.org Subject: Re: Problem running tests/client_test Steve Huston wrote: Hi James, This is a known issue: https://issues.apache.org/jira/browse/QPID-1733 I'm working on a fix for it. Workaround is to start with broker with --auth no. OK, thanks. Perhaps teh JIRA organisation could be improved? - the Java tests have a JIRA section and I looked for one for C++ - and I looked in the C++ client since it seems that the empty response from the client is in error rather than the list from the broker. Is teher a release note I've failed to read with this sort of thing in it? James - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
