[zeromq-dev] Fwd: Access control

Oliver Smith oliver at kfs.org
Tue Jul 27 18:06:57 CEST 2010


On 7/27/2010 10:54 AM, Pieter Hintjens wrote:
>> Wait - they can connect to our publisher: otherwise the Internet
>> wouldn't be much use from behind NAT. It's just making connections back
>> to them that's difficult.
>>      
> Of course they can connect to the publisher but there is no way for
> your application code to authenticate those connections.
>    

So, what I'm thinking is a zmq::authpub_t, which has as it's members 
both a zmq::rep_t and a zmq::pub_t, matched with a zmq::authsub_t, which 
has zmq::req_t and zmq::sub_t.

Messages received by the authpub_t would be assumed to be auth messages, 
and forwarded to the authpub_t owner to approve. Response routing is 
enabled for the socket at this point, so when the authpub_t owner next 
calls send() it is assumed to be a response to the last message.

During the authpub_t::send we'd do something like ('m_' prefix just to 
emphasize member variables in the absence of a full definition)

     if ( expectingAReply )
     {
         m_authConditionMet = 
this->hasSocketOption(ZMQ_AUTHPUB_AUTHORIZED) ;
         m_reqSocket.reply(msg) ;
         if ( m_authConditionMet )
         {
             // Clear the flag for future reference.
             this->setsockopt(ZMQ_AUTHPUB_AUTHORIZED, 0) ;
             this->xattach_pipes(...) ; // Transfer the connection from 
the reqSocket to the outgoing pipe list.
             // so the underlying connection is no-longer associated 
with the m_reqSocket.
         }
         m_expectingAReply = false ;
     }
     else
     {
         internalPubSocket.send(msg) ;
     }




More information about the zeromq-dev mailing list