По состоянию на 6 октября 2026 года, текущее руководство по самостоятельному размещению Jitsi по-прежнему поддерживает цель предоставления возможности создавать конференц-залы только аутентифицированным пользователям, позволяя гостям присоединяться к ним позже. Однако в руководстве теперь отмечается, что старая процедура «Защищенный домен» устарела для новых установок и вместо нее рекомендуется аутентификация на основе токенов. Правильная настройка зависит от способа установки Jitsi: это руководство предоставляет прямой путь внутренней аутентификации для развертывания Docker и объясняет текущее направление для новых установок Debian или Ubuntu.
Эти настройки определяют, кто может создавать комнаты. Они не делают автоматически каждую комнату приватной. Пароли для комнат, лобби и процесс приглашения — это отдельные элементы управления.
| Развертывание | Практичный выбор | Что оно контролирует |
|---|---|---|
| Официальное развертывание Docker Compose | Включите внутреннюю аутентификацию и создание учетных записей в Prosody. | Только созданные вами учетные записи могут начать конференцию; возможность присоединения гостей можно настроить. |
| Новая установка Debian или Ubuntu | Следуйте текущему руководству Jitsi по аутентификации с помощью токенов, в описанном примере которого используется Keycloak. | Только пользователи, получившие действительный токен из вашей системы идентификации, могут начать конференцию. |
| Существующая установка использует старую конфигурацию защищенного домена. | При планировании обновления оставляйте только устаревшую конфигурацию. | Более раннее разделение между аутентифицированным хостом и анонимным гостем |
В текущем руководстве по аутентификации Jitsi описывается создание аутентифицированных комнат с анонимными гостями, а на более старой странице, посвященной защищенному домену, прямо указано, что этот метод устарел для новых установок. Избегайте копирования старых настроек Prosody или Jicofo в более новую версию без проверки руководства, соответствующего вашему методу установки.
Данная процедура предполагает, что вы уже используете Jitsi Meet из официального проекта Docker Compose и можете редактировать его .envфайл. В приведенном ниже примере используется встроенный internalрежим аутентификации. Он не добавляет публичную страницу регистрации: администратор создает и удаляет разрешенные учетные записи.
Откройте .envфайл, используемый для развертывания Jitsi Compose. Установите переменные аутентификации следующим образом:
ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internalУбедитесь, что строки являются активными настройками, а не комментариями, начинающимися с #. При использовании ENABLE_GUESTS=1, пользователи, не вошедшие в систему, могут присоединиться в качестве гостей после того, как авторизованный пользователь откроет конференцию. Если вы хотите, чтобы каждый участник проходил аутентификацию, установите ENABLE_GUESTS=0; это изменит, кто может присоединиться, а не только кто может создавать комнаты.
В руководстве Docker описаны эти переменные и встроенный алгоритм работы с учетными записями. Актуальный список поддерживаемых типов и параметров аутентификации см. в разделе «Аутентификация» руководства Docker .
В каталоге, содержащем ваш файл Compose, примените обновленные настройки среды. Compose пересоздаст службы, конфигурация которых изменилась:
docker compose up -dПеред созданием учетных записей убедитесь, что контейнеры запущены. Если вы используете собственный проект Compose, другое имя проекта или уровень оркестровки, выполните соответствующее обновление для этого развертывания, а не запускайте второй стек Jitsi.
Откройте оболочку в контейнере Prosody:
docker compose exec prosody /bin/bashЗатем зарегистрируйте пользователя Jitsi в домене Docker XMPP по умолчанию:
prosodyctl --config /run/prosody/config/prosody.cfg.lua register <username> meet.jitsi <strong-password>Замените оба заполнителя именем пользователя и уникальным паролем для этого человека. Не используйте угловые скобки. Для второго авторизованного хоста выполните команду еще раз с другим именем пользователя. Показанная команда использует домен Docker по умолчанию meet.jitsi; если вы изменили его XMPP_DOMAIN, используйте домен, настроенный в вашем развертывании. В текущем руководстве Docker описана команда для контейнера Prosody и соответствующая команда для удаления.
Чтобы отозвать учетную запись пользователя, войдите в контейнер Prosody и выполните следующую команду:
prosodyctl --config /run/prosody/config/prosody.cfg.lua unregister <username> meet.jitsiСписок учетных записей должен быть ограничен лицами, имеющими право инициировать конференции. Название комнаты не является механизмом контроля доступа, и доступ к учетной записи следует удалять, когда организатор больше в нем не нуждается.
Используйте приватное окно браузера или отдельный профиль браузера, чтобы существующая сессия входа в Jitsi не скрывала результат. Откройте общедоступный URL-адрес Jitsi и попробуйте создать новую комнату без аутентификации. Перед созданием новой конференции система должна потребовать аутентификацию. Войдите в систему с одной из созданных вами учетных записей и создайте комнату; затем убедитесь, что комната открылась.
Далее откройте ссылку на конференцию в отдельном сеансе браузера без аутентификации. При включенном гостевом доступе гость сможет присоединиться к конференции после того, как авторизованный организатор начнет ее. В руководстве по Docker от Jitsi указано, что при включенном гостевом доступе пользователям без аутентификации необходимо дождаться аутентификации другого пользователя.
В текущем руководстве по самостоятельному размещению Jitsi представлен новый способ аутентификации с использованием токена. В описанном примере Jitsi подключается к Keycloak, настраивается хост Prosody для запроса токена и добавляется анонимный гостевой домен, когда гостям разрешен доступ. В конфигурации Jitsi в описанной настройке используются authentication = "token"и allow_empty_token = falseдля основного хоста, а затем гостевой домен сопоставляется как jitsi-anonymous. Следуйте полному руководству по аутентификации для области Keycloak, URL-адресов перенаправления клиента, маршрутизации обратного прокси, Prosody и настроек веб-клиента Jitsi. Замените каждое имя хоста в примере на свое собственное и обеспечьте защиту конечной точки поставщика идентификации с помощью HTTPS.
Аутентификация с помощью токенов полезна, когда управление учетными записями должно осуществляться поставщиком идентификации или когда ваше приложение выдает токены доступа для конкретных комнат. Для этого требуется правильно настроенный эмитент и проверка токенов; простое включение этой настройки в браузере не ограничивает безопасное создание комнат. Если вам нужны учетные записи с поддержкой LDAP в Docker, в руководстве по Docker также описан режим LDAP, но параметры подключения LDAP, сертификата и фильтра должны соответствовать вашему каталогу.
Аутентификация отвечает на вопрос «кто может начать конференцию?». Сама по себе она не отвечает на вопрос «кто может войти в эту комнату?». Если разрешен доступ гостям, любой, кто получит URL-адрес комнаты, сможет попытаться присоединиться. Добавьте пароль для комнаты или настройте лобби для встреч, которые должны допускать только приглашенных участников. В руководстве по самостоятельному размещению Jitsi различается возможность запуска конференций на уровне сервера и управление доступом в отдельной комнате.
ENABLE_AUTH=1активацию параметра в файле среды, используемом запущенным проектом Compose, а затем повторно примените конфигурацию.ENABLE_GUESTSотключена ли эта функция. Эта настройка требует аутентификации участников; она не нужна, если ваша цель — аутентификация организаторов с гостевыми участниками.meet.jitsi; для пользовательских доменов XMPP требуются соответствующие значения.ENABLE_GUESTSнастройках.Ключевое решение заключается в том, следует ли вашему экземпляру Jitsi использовать индивидуально созданные внутренние учетные записи или токены, выданные через поставщика идентификации. Для существующего развертывания Docker Compose внутренняя аутентификация — это прямой способ ограничить создание комнат небольшим набором зарегистрированных пользователей. Для новой установки начните с текущего руководства по аутентификации с помощью токенов и сохраните настройки контроля доступа на уровне комнат, настроенные отдельно.
Диагностика скачков загрузки ЦП в браузере Jitsi Meet и снижение нагрузки на клиентское приложение путем проверки видеофайлов, эффектов камеры, графики браузера и настроек хоста.
Отслеживайте состояние Jitsi Videobridge, загрузку конференций и трафик с помощью встроенной точки доступа Prometheus, а затем анализируйте и отображайте данные в виде графиков в Grafana.
Настройте собственный домен для Jitsi Meet Docker с указанием DNS, PUBLIC_URL, HTTPS, Let's Encrypt, портов брандмауэра, настроек NAT и сквозной проверки.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Узнайте, как диагностировать и устранять предупреждение Nextcloud о конфигурации PHP OPcache, проверив активные параметры PHP SAPI, ограничения размера, комментарии и настройки повторной проверки.
Для устранения неполадок, возникающих при миграции базы данных Kopano после обновления MySQL или MariaDB, проверьте резервные копии, версии серверов, режимы SQL, кодировку, состояние схемы и журналы.
Подключите Nextcloud к LDAP или Active Directory с помощью защищенного канала связи, фильтров пользователей и групп, атрибутов входа в систему и проверенной процедуры развертывания.
Исправление проблем с уведомлениями Element Android на телефонах без привязки к Google путем настройки UnifiedPush, разрешений Android, параметров батареи и надежных тестов проверки.
Удалите предупреждение Nextcloud об отсутствии индексов в базе данных с помощью официальной команды occ. Сначала сделайте резервную копию, просмотрите изменения, выполните восстановление и проверьте результат.
Настройте единый вход Keycloak для Element Web, подключив OIDC к Synapse, задав точный URL-адрес обратного вызова, сопоставив данные пользователя и протестировав выход из системы.
