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 [EMAIL PROTECTED] http://www.winterdom.com/weblog/
