[zeromq-dev] Confirm authentication and retrieve metadata?

[Steve Eley]

> On Apr 9, 2015, at 1:07 AM, Pieter Hintjens <ph at imatix.com> wrote:
> 
> zmq_connect doesn't expose security failures at all. These are visible
> in the server side via ZAP, and in the client side via monitor events.
> Also we added logging to libzmq in such cases.

Thanks Peter. That confirms my observations and answers my first question very well. But it leaves the second question open and possibly more important. If socket monitoring is the intended means for a client to detect that its security handshake failed, how does the client distinguish between a security-related disconnect and any other disconnect?  What's the unique event pattern that makes a security failure visible?

Also, while it's less important, I'd appreciate any insight on my metadata question. Pre-4.1, is there any way for the server _or_ client to retrieve the user ID or application-specific metadata returned by the ZAP handler? Post-4.1, is there any way to get it without a message being sent?


> You should read the CZMQ zauth class, and look at the examples on
> http://hintjens.com/blog:48. These will help a lot probably.

Thank you. I read your series of blog posts a number of times before starting on the design.  When I ran into these unknowns I did read the relevant CZMQ code, as well as the libzmq test cases and the curve_client.cpp and plain_client.cpp source.  All of that was very helpful in understanding the critical path, and I can see that client sockets do detect handshake failures and set a 'mechanism_t::error' status (though the error reason appears to be thrown away). What I can't figure out is how to see that error status using libzmq API calls so that I can tell the application what went wrong. Am I correct in concluding that there is no way?  If so, is this by design, or would an issue calling for a way to expose handshake status be well-received?


> If you are building a new Ruby wrapper then look at
> https://github.com/methodmissing/rbczmq.

Thanks once again. I'm a little familiar with that library (and somewhat more so with ffi-rzmq), and it appears to be good at what it does despite lacking security features. The reason I'm rolling my own instead of contributing to it is a philosophical difference. I don't want a Ruby library that acts like a C library, with the usage semantics that implies.  I want one that feels like Ruby -- initializer options, duck-typed messages, 'receive' methods that accept code blocks, etc. -- and I want all of the setup and teardown to be completely transparent.  The default Context springs into existence when the first Socket is created. Sockets are cleanly closed on garbage collection.  Stuff like that. 

If you're interested you can find my work-in-progress at https://github.com/sfeley/ezmq <https://github.com/sfeley/ezmq> . It all works pretty well except for the 4.x features I'm implementing now. (I know it needs to be renamed; there's a gem naming conflict that didn't exist when I started it. Unfortunately, all the 'obvious' names for a Ruby 0mq gem have already been taken, so unless one of the defunct gems is willing to give up their name, I'll probably have to call it something less than obvious. Such is life.)

Have Fun,
Steve Eley


> -Pieter
> 
> On Thu, Apr 9, 2015 at 3:59 AM, Stephen Eley <sfeley at gmail.com> wrote:
>> Hi all,
>> 
>> I'm trying to build a Ruby wrapper with simple support for some of 0mq's
>> newer features, including encryption and authentication. I believe I have a
>> pretty good handle on the socket options and how the ZAP authentication
>> handler needs to work. However, I've been conceptually hung up on how to
>> detect and pass failures back to the user application, and scouring Google
>> and the source code hasn't helped.
>> 
>> My questions:
>> 
>> 1. The RFCs all say that server sockets are to disconnect in the event of a
>> CURVE key or ZAP authentication failure. But the zmq_connect call doesn't
>> appear to wait for any of that, and even with ZMQ_IMMEDIATE set it doesn't
>> seem to have any relevant error codes. Short of setting up a
>> zmq_socket_monitor and listening for disconnect events in a dedicated
>> thread, is there any way I can figure out on the client end that a
>> connection never cleared security?
>> 
>> 2. If I did take the zmq_socket_monitor route, is there any way to tell the
>> difference between a ZMQ_EVENT_DISCONNECTED that happened because of a CURVE
>> or ZAP failure and one that happened for any other reason?
>> 
>> 3. The ZAP protocol defines a frame for a user ID "for use by applications."
>> There's another one for metadata with similar intent. However, I can't
>> figure out how the application is supposed to get ahold of that data. I see
>> that 0mq 4.1 has a zmq_msg_gets function for metadata on every message, but
>> that doesn't help current production users, and querying on received
>> messages seems like an odd place to get connection-level information that's
>> given exactly once. If that future functionality is the only way, how does
>> one go about getting metadata on a send-only socket?
>> 
>> Apologies if these are dumb questions and I missed something obvious. And
>> thanks in advance for any tips or pointers to example code.
>> 
>> 
>> Have Fun,
>> Steve Eley
>> 
>> 
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150409/95e6471b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4877 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150409/95e6471b/attachment.bin>