Azure / amqpnetlite

AMQP 1.0 .NET Library
Apache License 2.0
402 stars 145 forks source link

NonSASL client can connect and create session to SASL broker but unable to send messages #570

Closed AnodizedAluminum closed 1 year ago

AnodizedAluminum commented 1 year ago

Setup: Broker-Apache ActiveMQ 5.15.4, default configuration Client-AMQPNetLite 2.4.0, .net4.5 Code-fairly straightforward according to example code, initialize ConnectionFactory first, create Connection from ConnectionFactory, then create Session from Connection, then lastly, initialize SenderLink using Session and send message.

Issue: by default, ActiveMQ's amqp TransportConnector does not allow nonSASL connections. But if I try to connect to broker using anonymous connection, where username and password set to null:

Address fullAddress = new Address(host, port, null, null, path, scheme); Connection connection = factory.CreateAsync(fullAddress).Result;

it will still allow me to create the Connection Factory and Session. However the code errors out when attempting to create a SenderLink with the error of: $exception {"The protocol requested by peer '3 1 0 0' does not match expected '0 1 0 0'. Make sure both sides agree on protocol id and version."} Amqp.AmqpException

The exception occurs because broker is expecting SASL connection, but client is trying anonymous, which is fine. But shouldn't this error occur sooner at Connection connection = factory.CreateAsync(fullAddress).Result; ? If client and broker are trying to communicate using different protocols, that connection should be rejected out right, instead of opening a useless connection where all subsequent sends will fail. The use case for this is that I'm trying to create a test connection functionality. The test connection function will only create Connection and Session, which should be enough validate if user supplied connection info is valid. It seems to work in most cases except in the situation described above. Adding SenderLink creation to test connection function does not seem to be a good idea, because SenderLink requires user to supply a message address, which is supplied at send message time, and testing connection with a default/hardcoded address does not work when brokers can be configured to have strict access control that prevents client accessing to topics they don't have permission to. If there are alternative suggestions on how test connections should be done, I'm all ears too.

xinchen10 commented 1 year ago

Made a fix for the issue. The exception should be thrown now from CreateAsync call.