XMPP-белые списки?

У нас есть корпоративная установка QuickBlox (которая реализует XMPP) и хотела бы создать зеркальные учетные записи для всех наших пользователей на нашем Установка сервера QuickBlox. Мы также хотим синхронизировать сети, созданные пользователями системы, используя отношения (например, "клиент и поставщик" ), которые были построены в нашей системе.

Вкратце, мы хотим экспортировать белые списки, которые ограничивают "противников" чата только тем пользователям, с которыми у каждого из наших пользователей уже есть отношения. Если User1 имеет существующие отношения в нашей системе с User2 и User3, но не с User4 через User40, мы хотим иметь возможность использовать QuickBlox API для обеспечения соблюдения этого в чате путем создания белого списка через API QuickBlox.

РЕДАКТИРОВАТЬ: Мы не можем использовать белый список "система чести". То есть, принудительное выполнение должно быть на стороне сервера, используя метод, который клиент не может обойти. Между пользователями должен быть жесткий, неизбежный блок для защиты конфиденциальности.

Случай использования:

Сервер QuickBlox (или XMPP) имеет User1 через User40 включительно.

Белый список User1 состоит только из [User2, User3].

Если User1 пытается связаться с User15, мы хотим, чтобы QuickBlox/XMPP отмечал, что User15 не включен в белый список User1 и блокирует это сообщение, как если бы пользователь1 имел двунаправленный блокировку этого пользователя.

Списки конфиденциальности, а также черные списки

Я нашел места в документах QB, которые относятся к документам спецификации XMPP, и нашел концепцию списков конфиденциальности, которые, похоже, работают как черные списки:

Они предоставляют два стиля конфиденциальности черного списка:

Вы можете выбрать тип заблокированной логики (Список конфиденциальности). Есть 2 типы:

Блокировать в одном направлении. Вы заблокированы, но можете написать заблокированный пользователь.

Блокировать двумя способами. Вы заблокированы, и вы также не можете напишите заблокированному пользователю.

Белый список серверов (диалоговый уровень, а не пользователь)

Я также нашел документацию по "белым спискам" для серверов, которые, похоже, работают с диалоговом /jid, а не с пользователем, уровень:

https://xmpp.org/extensions/xep-0133.html#edit-whitelist

Сущность, добавленная в белый список, может быть JID любой формы, как указано в RFC 6120... белый список может препятствовать входящей связи, исходящей связи или обоим...

Реестры - только "наличие"?

Есть также списки, которые близки к "белым спискам", но в моем тестировании они не отображаются, чтобы ограничить связь между любыми двумя пользователями, которые не могут быть друг на друга.

https://quickblox.com/developers/Web_XMPP_Chat_Sample#Get_the_roster

То есть, я не настроил реестр в своем тестовом приложении, и пользователи могут создавать диалоги для групп и 1 на 1 чат, несмотря на то, что они явно не принимали никаких запросов в виде списка. В документах Android я нашел следующее в списках: "[Список] - это коллекция пользователей, для которых человек получает обновления присутствия". Я не верю, что это не блокирует каким-либо образом вне оповещения о присутствии.

Вопрос

Есть ли способ создать пессимистический белый список для каждого пользователя, который содержит только тех пользователей, с которыми разрешено общение? Или мы вынуждены создавать и поддерживать "обратные черные списки", где мы автоматизируем создание списков конфиденциальности для каждого нового пользователя, блокирующего каждого другого пользователя, а затем используем API для удаления тех, с которыми каждый пользователь должен иметь возможность общаться?

Если нам нужно использовать "обратные черные списки", есть ли способ, чтобы черный список по умолчанию применялся к каждому новому пользователю, который изначально блокирует связь с каждым другим пользователем уже в нашей системе QuickBlox?

(Опять же, мы не можем использовать списки "система чести". Если клиент должен запросить, чтобы белый список был активным до его использования, можно свободно открывать и затем изменить активные белые списки или если клиент может отказывается использовать список, который недостаточно безопасен.)

Ответ 1

Клиенты XMPP

Клиенты XMPP нуждаются в том, чтобы спросить других клиентов, поддерживают ли они получение нажатий через реле. Так как нажатие может быть отправлено из любого места, клиенты также смогут отправлять push-запросы непосредственно другим клиентам через реле, если у них есть токен своих друзей-белых списков. Им также необходимо будет ответить на запросы сервера XMPP для токенов белого списка, чтобы разрешить отправку посылов сервером, если сообщение отправлено клиентом, не поддерживающим прямой push.

Серверы XMPP

Серверы XMPP могут запрашивать своих подключенных клиентов, если они поддерживают push-реле и, если это так, пересылают сообщения, которые они получают на сервер ретрансляции, когда клиент находится в автономном режиме. Это потребует, чтобы сервер XMPP также получал маркер белого списка от пользователя.

Справка: см. ссылку

Ответ 2

Если мы говорим о протоколе XMPP - есть возможность блокировать любые сообщения из/в (см. пример 48)

Итак, по умолчанию вы можете установить его для каждого пользователя, например.

Затем, если нам нужно разрешить общение с кем-то конкретным, то вы можете добавить этого пользователя в свой список конфиденциальности с помощью action = allow и заказать больше, чем "полный блок". Вот на самом деле хороший пример реализации белого списка через Списки конфиденциальности, см. Пример 8:

и (3) 'special', что позволяет общаться только с тремя конкретных объектов.