Unable to connect using SASL ANONYMOUS #250
Comments
dnwe
added a commit
to dnwe/node-amqp10
that referenced
this issue
Sep 27, 2016
By providing a Sasl object to policy.connect.sasl (but no user+pass in the address), SASL ANONYMOUS will be used rather than plain AMQP. Fixes noodlefrenzy#250
dnwe
added a commit
to dnwe/node-amqp10
that referenced
this issue
Sep 28, 2016
By providing a Sasl object to policy.connect.sasl (but no user+pass in the address), SASL ANONYMOUS will be used rather than plain AMQP. Fixes noodlefrenzy#250
dnwe
added a commit
to dnwe/node-amqp10
that referenced
this issue
Sep 28, 2016
By providing a Sasl object to policy.connect.sasl (but no user+pass in the address), SASL ANONYMOUS will be used rather than plain AMQP. Fixes noodlefrenzy#250
dnwe
added a commit
to dnwe/node-amqp10
that referenced
this issue
Oct 4, 2016
By specifying an explicit Sasl mechanism via policy.connect.saslMechanism, the user may opt-in to using/not-using a particular Sasl security layer for AMQP. Where: - **null** means: infer from the other policy settings and value supplied to connect (behaviour exactly as we have today, the default in policy.js) - **NONE** forces you not to attempt any SASL, raw AMQP only - if username / password are in the URL, they are ignored. - **PLAIN** forces you to try SASL plain - it's a client-side error not to have a username and password in the URL - **ANONYMOUS** forces you to try SASL anonymous - if username / password are in the URL, they are ignored. - **ANYTHING_ELSE** throws unsupported mechanism error Fixes noodlefrenzy#250
dnwe
added a commit
to dnwe/node-amqp10
that referenced
this issue
Oct 4, 2016
By specifying an explicit Sasl mechanism via policy.connect.saslMechanism, the user may opt-in to using/not-using a particular Sasl security layer for AMQP. Where: - **null** means: infer from the other policy settings and value supplied to connect (behaviour exactly as we have today, the default in policy.js) - **NONE** forces you not to attempt any SASL, raw AMQP only - if username / password are in the URL, they are ignored. - **PLAIN** forces you to try SASL plain - it's a client-side error not to have a username and password in the URL - **ANONYMOUS** forces you to try SASL anonymous - if username / password are in the URL, they are ignored. - **ANYTHING_ELSE** throws unsupported mechanism error Fixes noodlefrenzy#250
dnwe
added a commit
to dnwe/node-amqp10
that referenced
this issue
Oct 4, 2016
By specifying an explicit Sasl mechanism via policy.connect.saslMechanism, the user may opt-in to using/not-using a particular Sasl security layer for AMQP. Where: - **null** means: infer from the other policy settings and value supplied to connect (behaviour exactly as we have today, the default in policy.js) - **NONE** forces you not to attempt any SASL, raw AMQP only - if username / password are in the URL, they are ignored. - **PLAIN** forces you to try SASL plain - it's a client-side error not to have a username and password in the URL - **ANONYMOUS** forces you to try SASL anonymous - if username / password are in the URL, they are ignored. - **ANYTHING_ELSE** throws unsupported mechanism error Fixes noodlefrenzy#250
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently node-amqp10 supports either the raw AMQP protocol (for non-authenticated connections), or AMQP with a SASL PLAIN security layer (for authenticated connections). It would be helpful to additionally provide a policy for connecting with a SASL ANONYMOUS layer when no credentials are provided.
(I'll submit a PR shortly with an initial proposal)
The text was updated successfully, but these errors were encountered: