On Oct 15, 2014, at 11:09 AM, Robbie Gemmell wrote:
> What Ted already implemented on the C side would enable what you are
> seeking, allowing the server to be configured (depending on your security
> configuration; some wouldnt want the without-sasl case to ever work, other
> may allow it in no
What Ted already implemented on the C side would enable what you are
seeking, allowing the server to be configured (depending on your security
configuration; some wouldnt want the without-sasl case to ever work, other
may allow it in no-auth scenarios) to accept either the sasl or non sasl
header a
I think you should have an event for SASL_NEGOTATION.. or any name you chose..
then you could negotiate it properly. I don't think it would be too hard to
implement.
The clients I'm working don't know how to negotiate ANONYMOUS. All the Java
clients I'm dealing with now will throw a bad NPE if
Hi Clebert,
As a little extra context for readers...with AMQP 1.0, if the client wishes
to use SASL security it first establishes a SASL layer beginning with the
AMQP%d3.1.0.0 header, and then if successfull proceed to establish the
'regular' AMQP connection over it beginning with the AMQP%d0.1.0.
qpid JMS clients currently expect to send anonymous connection in the following
way:
- if the first frame has the SASL byte 3 (I'm not reading the spec now.. I'm
not sure the correct term), the server is supposed to initialize SASL on the
connection, transport... etc
In other terms, if the fol
