.NET client authentication status

[Tomas Restrepo <to...@devdeo.com>]

Hi everyone,

I was finally able to fully build and run the java broker (thanks to all for
the help!), so I was able to test a bit my authentication support for the
.NET client.

Current Status:
I have both authentication success and failure unit tests working with
CRAM-MD5.
Only success is working with PLAIN authentication (more about this in a
bit).

I had to do a few other modifications around including improving a bit of
the error handling code. I also had to do the following tasks:

1- Port the AMQConstant class with all the error codes from the Java common
library into Qpid.Common.
2- Port the AMQAuthenticationException class which was missing from the .NET
client
3- Modify the ConnectionCloseMethodHandler class to correctly handle the
case where the server responded with an authentication failure so that the
proper AMQAuthenticationException exception is thrown.

During this, however, I ran into a few snags I'm not 100% sure about and
would like some comments/guidance:

a- For some reason, the PasswordFailureConnection test fails if PLAIN
authentication is chosen. It appears that the server never responds with a
503 - NOT ALLOWED error in this case. Is this expected/known? Or is there
something I'm missing here? 
It's worth noting that the only reason the test was passing previously was
because it was incorrectly written.

b- Right now, when a connection is failing because of an authentication
error, a generic AMQException is getting thrown with the
AMQAuthenticationException as the InnerException. Is this OK? I don't quite
like it, but changing it would require a bit of messing around with the way
exceptions are being handled when trying connection against all configured
servers (i.e. failover). What do you guys think?

c- Right now, my implementation of CallbackHandlerFactory has the set of
Callback handlers hardcoded. Thus of the set of authentication mechanisms is
currently static (and the order of preferred mechanisms as well). Obviously
it would be better to have this configurable. 

That said, I believe the client should be fairly self-contained (or at least
I know that would be my preference for the kind of things I have in mind to
do with the client) and not have it depend explicitly on external
configuration unless totally necessary (this might be a topic for a separate
discussions as this is not the case right now). I'm thinking we could have a
default set of supported protocols/handlers if no external configuration is
found (and maybe create a custom app.config configuration section for new
client settings). 

Any thoughts?

Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/

RE: .NET client authentication status

[Tomas Restrepo <to...@devdeo.com>]

> a- For some reason, the PasswordFailureConnection test fails if PLAIN
> authentication is chosen. It appears that the server never responds with a
> 503 - NOT ALLOWED error in this case. Is this expected/known? Or is there
> something I'm missing here?

I meant 530 - NOT ALLOWED. Sorry.

Tomas Restrepo
tomas@winterdom.com
http://www.winterdom.com/weblog/