[zeromq-dev] Is ZMQ_PLAIN authentication supposed to do anything?

[Min RK]

On Sep 2, 2013, at 9:25, Pieter Hintjens <ph at imatix.com> wrote:

> MinRK,
> 
> I've just pushed a patch that fixes authentication for PLAIN and
> CURVE, and updated the test cases to match.
> 
> It all works as expected... :-)
> 
> One thing about CURVE authentication; client keys are passed to the
> ZAP handler as 32 binary bytes. I'm wondering whether it would be
> nicer to pass Z85 text strings instead, as everything else in ZAP is
> text. I expect keysstored in databases and files to be in Z85, not
> binary... any thoughts?

I would leave it as bytes, personally. To me, z85 is convenience format for humans / text-only storage.  If the keystore stores keys that are not raw, I would expect the zap_handler to be responsible for the conversions.


> 
> -Pieter
> 
> 
> On Sun, Sep 1, 2013 at 7:14 PM, Pieter Hintjens <ph at imatix.com> wrote:
>> 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 <benjaminrk at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Aug 30, 2013 at 1:37 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>>> 
>>>> On Thu, Aug 29, 2013 at 1:32 AM, MinRK <benjaminrk at 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 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
>>> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev