I can think of making this easier if the ZMQ identites could be renegotiated, that way portion of the ID could be reserved for negotiation and then used as references. Don't know if this fits well with ZMQ's internals though.
-Mark On Thu, Mar 14, 2013 at 9:10 AM, A. Mark <gougol...@gmail.com> wrote: > > Hi Alexandre, > > Not certain what you mean by authentication but I have been thinking of > this ZMQ area just recently. What I did and I'm not sure that it is > relevant to your case is to have a ZMQ_ROUTER to ZMQ_ROUTER broker as the > server frontend+backend. I authenticate via the identity first which has a > specific but random format, then I ask for a password also. When this very > insecure "authentication" is successful the server assigns a "worker/app" > on the backend socket an index which is just a lookup to find the worker > easily later. The worker index is sent to the client in an envelope and > then it is required afterwards that the client use the identity+envelope it > got from the server for any subsequent messages. This way the server > immediately knows an authenticated client even after disconnect and finds > the corresponding worker very fast by the index inside the envelope. If > there is no envelope we know the client is not yet connected or it has > abandoned the state. > > > > On Thu, Mar 14, 2013 at 1:08 AM, Pieter Hintjens <p...@imatix.com> wrote: > >> Hi Alexandre, >> >> You could authenticate using the client identity but it's all in plain >> text. Disconnects/reconnects will then be invisible. As long as the >> client keeps whatever state is needed to continue the conversation, >> you don't need to reauthenticate. >> >> A better answer would be to use properly secure authentication. It's >> an area we're working on, see http://hintjens.com/blog:34 >> >> -Pieter >> >> On Wed, Mar 13, 2013 at 3:29 PM, Alexandre Fromage <a...@taxistop.com> >> wrote: >> > Dear all, >> > >> > A more appropriate subject would have been “Associate an identity to a >> given >> > client”, but “Identity” has a specific (close) meaning for ZeroMQ. >> > >> > I have a ROUTER and I would like, at application level to associate each >> > client (DEALER) generated id to an application context. For example, >> > associate, for the time of the connection, >> > >> > the ZeroMQ auto-generated connection id to a given user account. >> > >> > It is in itselft easy to do, but: >> > >> > each time there is a disconnection/reconnection (may happen a lot) I >> need to >> > immediately re-authenticate the client when it reconnects. However, it >> needs >> > to happen >> > >> > before the client resends all its outstanding requests to the server >> (which >> > are queued within the DEALER). >> > >> > Right now, I can only think of two things, either: >> > >> > -discard all messages which come when the client is not yet >> re-authenticated >> > (a bit extreme and consumes bandwidth for nothing). >> > >> > -modify the Zmq protocol to enforce authentication when connection is >> > (re)established. >> > >> > I believe I cannot use ZeroMQ identities as my clients have constantly >> > changing addresses. >> > >> > >> > >> > Do you think any of those possibilities make sense? >> > >> > Any suggestion? >> > >> > >> > >> > Thank you, >> > >> > >> > >> > Kind regards, >> > >> > >> > >> > Alex >> > >> > >> > _______________________________________________ >> > 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
