That seems the simplest and cleanest result. We'll get authentication failed events via the ZAP handler, and we might see connection failed event at the client side too (via context monitor) but these should be invisible to message processing.
-Pieter On Fri, Aug 30, 2013 at 11:50 PM, MinRK <benjami...@gmail.com> wrote: > > > > On Fri, Aug 30, 2013 at 1:37 PM, Pieter Hintjens <p...@imatix.com> wrote: >> >> On Thu, Aug 29, 2013 at 1:32 AM, MinRK <benjami...@gmail.com> wrote: >> >> > Thanks. By closed, you mean the connecting peer (client) should be >> > closed, >> > or the inner pipe on the server side? What should be the user-visible >> > symptoms of failed authentication, both on the client side and the >> > server >> > side, if any? I'm looking to add a failed-auth test to test_security, >> > but it >> > is unclear to me what the expected behavior is. Is the symptom only >> > that >> > messages sent do not arrive, or should sending a message not succeed in >> > the >> > first place? >> >> I think the net result of a failed authentication should be the same >> as if there was no network connection; no pipes created on either side >> of the connection, and no route to or from the unauthenticated client. > > > Thanks - so as far as the connecter is concerned, it is as if the peer is > unavailable, > and for the binder, it is as if nobody connected. > >> >> >> -Pieter >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
