Как настроить шаблон ZMQ PUB / SUB для обслуживания только для предварительно авторизованных подписчиков
Как я могу реализовать или сделать вид «взломать» в ПАБ—SUB шаблон, чтобы получить возможность публиковать только уполномоченный абоненты, Отключить неавторизованные подписчики и т.д.
Я погуглил эту проблему, но все ответы очень похожи на настройку фильтра подписки на стороне подписчика.
Но я хочу, как я уже сказал, публиковать свои обновления от ПАБ только тем клиентам, которые прошли авторизацию или имеют какой-то секрет key, что было получено в REQ—REP.
Спасибо за любые идеи.
Решение
Прочитайте главу 5 руководства, конкретно раздел под названием «Плюсы и минусы Pub-Sub».
Есть много проблем, связанных с тем, что вы пытаетесь достичь, так же, как вы пытаетесь это сделать (но есть решения, если вы хотите изменить свою архитектуру).
- Предположительно, вам нужно, чтобы PUB-сокет был общедоступным для всего мира, будь то мир в целом или просто мир, состоящий из нескольких сокетов, которые разрешены, и нескольких сокетов, которых нет. Если нет, вы можете просто контролировать доступ (через брандмауэр) к самому разъему PUB только к авторизованным машинам / сокетам.
- Когда PUB-сокет получает новое соединение, он не знает, авторизован ли подписчик или нет. PUB не может получить реальную связь от SUB-сокетов, поэтому SUB-сокет не может напрямую сообщить о своей авторизации. Сокеты XPUB / XSUB преодолевают это ограничение, но оно вам не поможет (см. Ниже).
- Как бы вы ни передавали авторизацию SUB-сокета в PUB-сокет, я не знаю тем не мение для сокета PUB уничтожить или проигнорировать соединение сокета SUB, если оно не авторизовано. Это означает, что ненадежный SUB-сокет может подписаться на ALL (») и получать все сообщения от PUB-сокета, а PUB-сокет ничего не может с этим поделать. Если вы доверять SUB-сокет для самоконтроля (вы создаете соединительный сокет и управляете машинами, на которых он развернут), затем у вас есть возможность просто подписаться на «контрольную» тему, отправить авторизацию и получить от PUB-сокета обратную связь по каналам / темам. на что вам разрешено подписаться.
Таким образом, это в значительной степени убивает его для достижения общей безопасности в общедоступной парадигме PUB / SUB.
Вот ваши варианты:
- Отказаться от PUB / SUB — Единственный способ, которым вы можете точно контролировать, какой узел вы отправляете каждый раз на стороне отправителя (о чем я знаю), — это использование разъема ROUTER. Если вы используете ROUTER / DEALER, сокет DEALER может отправить свою авторизацию, сокет ROUTER хранит ее со своим идентификатором, а когда что-то нужно отправить, он просто находит все подключенные сокеты, которые авторизованы, и отправляет их последовательно каждому из них. Реально это или нет, зависит от количества сокетов и рабочей нагрузки (размер и количество сообщений).
- Зашифруйте ваши сообщения — Вы уже сказали, что это ваше последнее средство, но это может быть единственным возможным ответом. Как я уже говорил выше, любой SUB-сокет, который может получить доступ к вашему PUB-сокету, может просто подписаться на ВСЕ (») отправляемые сообщения без надзора. Вы не можете эффективно скрыть адрес / порт вашего PUB-сокета, вы не можете скрыть любые сообщения, отправляемые через этот PUB-сокет, но вы можете скрыть содержимое этих сообщений с помощью шифрования. Правильный метод обмена ключами зависит от вашей ситуации.
Другие решения
Поскольку Джейсон показал вам отличный обзор того, почему (не забудьте добавить +1 к его замечательному ответу, хорошо?), Позвольте мне добавить два моих цента о том, как:
Q: как?
A: Забудьте про архетип PUB / SUB и создайте конкретный случай
Да. ZeroMQ — это очень мощный набор инструментов, который можно сделать, а не коробку конфет, которую вам запрещено пробовать и выбирать для создания следующего супер-кода.
Таким образом, ваш код остается и остается способным установить как элементы управления, так и меры для неконтролируемого в противном случае SUBповедение стороннего кода.
Создание собственного, составного, многоуровневого решения для обмена сообщениями — это та мощь, которую ZeroMQ привносит в ваши проекты. Там вы понимаете, что вы мастер проектирования распределенных систем. Помимо академических примеров, никто не использует простые примитивные архетипы поведения, но обычно составляет более надежные и реалистичные шаблоны составных сообщений для решений производственного уровня.
Нет простого однострочного варианта, чтобы заставить ваш вариант использования системы работать.
Хотя это не обязательно отвечать на все ваши данные, вы можете прочитать замечания