How to set up ZMQ PUB / SUB template to use for pre-authorized subscribers (subscribers) only
How can I implement or make a kind of "hack" in the template - to be able to publish only authorized , disable unauthorized subscribers, etc. PUB SUB
I searched for this problem, but all the answers are very similar to a set of subscriber side filters.
But I want, as I said, to publish my updates from PUBonly those clients who have passed authorization, or have a secret one that was received in -. key
REQ REP
Thanks for any ideas.
source to share
Read Chapter 5 of the Guide , in particular the Pros and Cons of Pub-Sub.
There are many problems with what you are trying to accomplish the way you are trying it (but there are solutions if you want to change your architecture).
- Presumably you want the PUB socket to be generally accessible to the world, be it the world in general, or just a world made up of some sockets that are allowed and some sockets that are not. If not, you can simply control access (through the firewall) to the PUB socket itself to only authorized machines / sockets.
- When a PUB socket gets a new connection, it doesn't know if the subscriber is allowed or not. The PUB cannot receive the actual message from the SUB sockets, so there is no way to directly connect the SUB socket to its authorization. XPUB / XSUB sockets violate this limitation, but it won't help you (see below).
- Regardless of how you pass SUB socket authorization to a PUB socket, I don't know how for a PUB socket it is possible to kill or ignore a SUB socket connection if it is not allowed. This means that an untrusted SUB socket can subscribe to ALL ('') and receive all messages from the PUB socket, and the PUB socket cannot do anything about it. If you trust the police SUB socket (you create a connection socket and control the machines it is deployed to) then you have the options to simply subscribe to the "control" topic, send authorization, and set the PUB socket to return pipes / topics. who are allowed to subscribe to.
So it pretty much kills it for achieving general security in the PUB / SUB paradigm that is publicly available.
Here are your options:
- Abandon PUB / SUB . The only way you can accurately control which peer you send each time on the sending side (which I know) is with the ROUTER socket. If you are using ROUTER / DEALER, the DEALER socket can send its authorization, the ROUTER socket stores it with its ID, and when something needs to be sent, it just finds all connected sockets that are authorized and sends them sequentially on each of them. Whether this is possible or not depends on the number of sockets and the workload (size and number of messages).
- Encrypt your messages . You have already said that this is your last resort, but it may be the only possible answer. As I said above, any SUB socket that can access your PUB socket can simply subscribe to ALL ('') messages sent without any control. You cannot hide your PUB socket address / port, you cannot hide any messages sent through that PUB socket, but you can hide the content of those messages using encryption. The correct method for separating keys depends on your situation.
source to share
As Jason showed you a great overview on why (don't forget to add +1 to his great answer, okay?), Let me add my two cents on how:
Q: How?
A: Forget the PUB / SUB archetype and create a specific case
Yes. ZeroMQ is a very powerful can-do toolkit, not a box of chocolates that you are not allowed to try and choose to build the next supercode.
This way, your code remains and remains in place to set both controls and measures for uncontrolled behavior - SUB
protected code.
Building one custom, composite, tiered messaging solution is the most powerful ZeroMQ feature for your projects. There you understand that you are a master of distributed system development. Apart from academic examples, no one uses simple primitive behaviors, but usually provide more robust and realistic composite messaging patterns for production-grade solutions.
There is no simple one-liner to work with in your system mode.
As long as you don't need to reply to all your data, you can read the notes
source to share