[rabbitmq-discuss] how to detect bad username/password in 0.9.5?

[Brandon Craig Rhodes]

When a error occurs while connecting in Pika 0.9.5, I have to go log on
to my RabbitMQ server and look at its logs to discover what happened -
the IOLoop in the local program simply returns after three seconds and
my next piece of code breaks because the `on_open_callback` callback
that I am passing to my `SelectConnection` never gets called when the
username and password are wrong.

How am I supposed to intercept this condition so that I can return an
error message to my user? I tried registering a callback with the
`connection.add_on_close_callback()` method but, sensibly enough, it
never gets called because this is not really a connection-close, but a
connection not getting established in the first place. I have looked
around for some sort of a `connection.add_on_error_callback()` or some
similar sort of facility, but cannot find one.

How do I catch and handle asynchronous errors?

Thanks for ANY help that you guys can offer - and thanks, Gavin, for
writing such an important part of the modern Python ecosystem!

--
Brandon Craig Rhodes bra...@rhodesmill.org http://rhodesmill.org/brandon
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Gavin M. Roy]

In trying to track this down with RabbitMQ 2.4.1 and Pika 0.9.6pre0 I am not seeing any reply back from Rabbit after a Connection.StartOk is sent, the socket just closes.

Is this expected behavior from the broker perspective?  I imagine since the connection is never negotiating doing a Connection.Close from the server is not appropriate.  Any suggestions on how to raise this as an Exception since it seems to be an implied behavior that broker disconnects if the mechanism or response values are incorrect?

The error logs do show the error as expected.

=ERROR REPORT==== 9-May-2011::11:05:32 ===

exception on TCP connection <0.6098.0> from 127.0.0.1:58311

{channel0_error,starting,

                {amqp_error,access_refused,

                            "PLAIN login refused: user 'gmr' - invalid credentials",

                            'connection.start_ok'}}

=INFO REPORT==== 9-May-2011::11:05:32 ===

closing TCP connection <0.6098.0> from 127.0.0.1:58311

[Emile Joubert]

On 09/05/11 16:12, Gavin M. Roy wrote:
> In trying to track this down with RabbitMQ 2.4.1 and Pika 0.9.6pre0 I am
> not seeing any reply back from Rabbit after a Connection.StartOk is
> sent, the socket just closes.
>
> Is this expected behavior from the broker perspective?

Indeed, AMQP says:

"""
There is no hand-shaking for errors on connections that are not fully
open. [...P]rior to sending or receiving Open or Open-Ok, a peer that
detects an error MUST close the socket without sending any further data.
"""

The names of exceptions thrown by other RabbitMQ libraries when this
condition is encountered (e.g. PossibleAuthenticationFailureException)
aim to provide a hint that incorrect login details are the leading cause
of problems in this area.

-Emile

[Michael Klishin]

On lunedì 9 maggio 2011 at 19.12, Gavin M. Roy wrote:
> In trying to track this down with RabbitMQ 2.4.1 and Pika 0.9.6pre0 I am not seeing any reply back from Rabbit after a Connection.StartOk is sent, the socket just closes.
>
> Is this expected behavior from the broker perspective?

Yes. AMQP 0.9.1 spec dictates that before connection is open, any peer that detects connection-level exception must close TCP connection without sending any more data.

> I imagine since the connection is never negotiating doing a Connection.Close from the server is not appropriate. Any suggestions on how to raise this as an Exception since it seems to be an implied behavior that broker disconnects if the mechanism or response values are incorrect?

Several client libraries keep track of whether authentication was started and finished. If TCP connection is closed and
we are in the "still authenticating" state, they raise an exception that hints at possible authentication failure.

amqp gem and Java client work this way and raise PossibleAuthenticationFailureError and PossibleAuthenticationFailureException, respectively.
--
MK

[Gavin M. Roy]

Based on the follow-up emails, I'll have an Exception raised when the connection closes after start-ok in 0.9.6.

Gavin

On Thursday, May 5, 2011 at 11:17 AM, Brandon Craig Rhodes wrote:

[Michael Klishin]

Gavin,

I see that pika is callbacks-oriented. If so, maybe it can do what amqp gem does: it actually runs an errback when possible authentication failure is detected, but also provides a default callback that raises an exception. This way library user can choose between the two and failure to define the errback is visible. Just a suggestion.

--
MK

On lunedì 9 maggio 2011 at 20.26, Gavin M. Roy wrote:
> Based on the follow-up emails, I'll have an Exception raised when the connection closes after start-ok in 0.9.6.
>

_______________________________________________

[Gavin M. Roy]

On Mon, May 9, 2011 at 1:02 PM, Michael Klishin <michael....@gmail.com> wrote:

Gavin,

I see that pika is callbacks-oriented. If so, maybe it can do what amqp gem does: it actually runs an errback when possible authentication failure is detected, but also provides a default callback that raises an exception. This way library user can choose between the two and failure to define the errback is visible. Just a suggestion.

Thanks, that sounds like a good solution. The main issue right now is we don't start tracking state for callbacks until after the connection is negotiated and do so based upon frames.  It should be trivial to add the right kind of errback prior to connection.open-ok, I just want to make sure I implement it correctly where it comes across as a kludgy after-thought.

Gavin

[Brandon Craig Rhodes]

"Gavin M. Roy" <g...@myyearbook.com> writes:

> On Mon, May 9, 2011 at 1:02 PM, Michael Klishin
> <michael....@gmail.com> wrote:
>
>> I see that pika is callbacks-oriented. If so, maybe it can do what
>> amqp gem does: it actually runs an errback when possible

>> authentication failure is detected...

> Thanks, that sounds like a good solution.

Gavin, thank you for looking into this! A callback will be perfect, and
let me clean things up and alert the user when communication is not
taking place.

If you have a Stack Overflow account, feel free to leave the true
answer, "the AMQP protocol has no concept of a 'bad password' response
but we can raise an exception if we are hung up on," on the question I
asked and receive the green check-mark of victory:

http://stackoverflow.com/questions/5918316/how-can-python-detect-that-my-rabbitmq-password-failed/

--
Brandon Craig Rhodes bra...@rhodesmill.org http://rhodesmill.org/brandon