auth mechanisms were only enabled when ZMTP handshake
is latest version, meaning that connections from old sockets
would skip authentication altogether
This is still raw and experimental.
To connect through a SOCKS proxy, set ZMQ_SOCKS_PROXY socket option on
socket before issuing a connect call, e.g.:
zmq_setsockopt (s, ZMQ_SOCKS_PROXY,
"127.0.0.1:22222", strlen ("127.0.0.1:22222"));
zmq_connect (s, "tcp://127.0.0.1:5555");
Known limitations:
- only SOCKS version 5 supported
- authentication not supported
- new option is still undocumented
NULL mechanism sends ERROR command rather than READY command when ZAP
handler rejects the ZAP request (status code != "200"). The body of
ERROR command contains the status code as returned by ZAP handler.
When a ZMQ_STREAM socket connection is broken (intentionally, via `shutdown()`
or accidentally via client crash or network failure), there is no way for the
application to dertermine that it should drop per-connection data (such as
buffers).
This contribution makes sure the application receives a 0-length message to
notify it that the connection has been broken. This is symmetric with the
process of closing the connection from within the application (where the
application sends a 0-length message to tell ZeroMQ to close the connection).
Conflicts:
CMakeLists.txt
The get_credential () member function returns
credential for the last peer we received message for.
The idea is that this function is used to implement user-level API.
This reverts commit f27eb67e1abb0484c41050e454404cce30647b63, reversing
changes made to a3ae0d4c16c892a4e6c96d626a7c8b7068450336.
https://zeromq.jira.com/browse/LIBZMQ-576
Conflicts:
src/stream_engine.cpp
Conflicts were around additional defaults to the constructor after the
'terminating' default. The additional defaults were left alone, and
the 'terminating' default was removed.
- This seems redundant; is there a use case for NOT providing
the IPC credentials to the ZAP authenticator?
- More, why is IPC authentication done via libzmq instead of ZAP?
Is it because we're missing the transport type on the ZAP request?
Another take on LIBZMQ-568 to allow filtering IPC connections, this time
using ZAP. This change is backward compatible. If the
ZMQ_ZAP_IPC_CREDS option is set, the user, group, and process IDs of the
peer process are appended to the address (separated by colons) of a ZAP
request; otherwise, nothing changes. See LIBZMQ-568 and zmq_setsockopt
documentation for more information.
* Command names changed from null terminated to length-specified
* Command frames use the correct flag (bit 2)
* test_stream acts as test case for command frames
* Some code cleanups
