Od 6 października 2026 roku aktualny podręcznik samodzielnego hostingu Jitsi nadal wspiera cel, jakim jest umożliwienie tworzenia sal konferencyjnych tylko uwierzytelnionym użytkownikom, a gościom późniejszego dołączenia. Jednak podręcznik oznacza starszą procedurę „Bezpiecznej domeny” jako przestarzałą dla nowych instalacji i zaleca zamiast niej uwierzytelnianie oparte na tokenach. Prawidłowa konfiguracja zależy od sposobu instalacji Jitsi: ten podręcznik podaje bezpośrednią ścieżkę uwierzytelniania wewnętrznego dla wdrożeń Dockera i wyjaśnia obecny kierunek dla nowych instalacji Debiana lub Ubuntu.
Te ustawienia regulują, kto może założyć pokój. Nie oznaczają one automatycznie, że każdy pokój jest prywatny. Hasła do pokoi, dostęp do lobby i proces zapraszania to osobne ustawienia.
| Zastosowanie | Praktyczny wybór | Co kontroluje |
|---|---|---|
| Oficjalne wdrożenie Docker Compose | Włącz uwierzytelnianie wewnętrzne i twórz konta w Prosody | Tylko konta, które utworzysz, mogą rozpocząć konferencję; dołączanie gości jest konfigurowalne |
| Nowe wdrożenie Debiana lub Ubuntu | Postępuj zgodnie z aktualnym przewodnikiem Jitsi dotyczącym uwierzytelniania tokenami, w którym w udokumentowanym przykładzie wykorzystano Keycloak | Konferencję mogą rozpocząć tylko użytkownicy, którzy otrzymają ważny token z Twojego przepływu tożsamości |
| Istniejąca instalacja wykorzystująca starą konfigurację bezpiecznej domeny | Zachowaj tę konfigurację wyłącznie jako starszą podczas planowania aktualizacji | Starszy podział na uwierzytelnionego gospodarza i anonimowego gościa |
Aktualny przewodnik uwierzytelniania Jitsi opisuje uwierzytelniane tworzenie pokoi dla anonimowych gości, a starsza strona Secure Domain wyraźnie informuje, że ta metoda jest przestarzała w przypadku nowych instalacji. Unikaj kopiowania starych ustawień Prosody lub Jicofo do nowszej instalacji bez sprawdzenia przewodnika odpowiadającego Twojej metodzie instalacji.
Ta procedura zakłada, że korzystasz już z Jitsi Meet z oficjalnego projektu Docker Compose i możesz edytować jego .envplik. Poniższy przykład wykorzystuje wbudowany internaltryb uwierzytelniania. Nie dodaje on publicznej strony rejestracji: administrator tworzy i usuwa konta, do których ma uprawnienia.
Otwórz .envplik używany przez wdrożenie Jitsi Compose. Ustaw zmienne uwierzytelniania w następujący sposób:
ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internalUpewnij się, że wiersze zawierają aktywne ustawienia, a nie komentarze zaczynające się od #. Dzięki ENABLE_GUESTS=1osoby niezalogowane mogą dołączyć jako goście po otwarciu konferencji przez uwierzytelnionego użytkownika. Jeśli chcesz, aby każdy uczestnik się uwierzytelnił, ustaw ENABLE_GUESTS=0; – zmienia to, kto może dołączyć, a nie tylko kto może tworzyć pokoje.
Przewodnik po Dockerze dokumentuje te zmienne i wbudowany przepływ pracy dla kont. Aktualną listę obsługiwanych typów i opcji uwierzytelniania można znaleźć w sekcji Uwierzytelnianie w Dockerze .
Z katalogu zawierającego plik Compose zastosuj zaktualizowane środowisko. Compose odtworzy usługi, których konfiguracja uległa zmianie:
docker compose up -dPrzed utworzeniem kont sprawdź, czy kontenery są uruchomione. Jeśli używasz niestandardowego projektu Compose, innej nazwy projektu lub warstwy orkiestracji, uruchom odpowiednią aktualizację dla tego wdrożenia zamiast uruchamiać drugi stos Jitsi.
Otwórz powłokę w kontenerze Prosody:
docker compose exec prosody /bin/bashNastępnie zarejestruj użytkownika Jitsi w domyślnej domenie Docker XMPP:
prosodyctl --config /run/prosody/config/prosody.cfg.lua register <username> meet.jitsi <strong-password>Zastąp oba symbole zastępcze nazwą użytkownika i unikalnym hasłem tej osoby. Nie dodawaj nawiasów kątowych. W przypadku drugiego autoryzowanego hosta uruchom polecenie ponownie z inną nazwą użytkownika. Wyświetlone polecenie używa domyślnej domeny Dockera meet.jitsi; jeśli zmieniłeś domenę XMPP_DOMAIN, postępuj zgodnie z domeną skonfigurowaną we wdrożeniu. Aktualny przewodnik po Dockerze opisuje polecenie kontenera Prosody i powiązane polecenie usuwania.
Aby cofnąć uprawnienia użytkownika, wejdź do kontenera Prosody i uruchom:
prosodyctl --config /run/prosody/config/prosody.cfg.lua unregister <username> meet.jitsiOgranicz listę kont do osób, które powinny móc inicjować konferencje. Nazwa pokoju nie jest mechanizmem kontroli dostępu, a dostęp do konta powinien zostać usunięty, gdy organizator nie będzie już go potrzebował.
Użyj prywatnego okna przeglądarki lub osobnego profilu przeglądarki, aby istniejąca sesja logowania Jitsi nie ukrywała wyniku. Otwórz publiczny adres URL Jitsi i spróbuj utworzyć nowy pokój bez uwierzytelniania. Instancja powinna wymagać uwierzytelnienia przed przydzieleniem nowej konferencji. Zaloguj się na jedno z utworzonych kont i utwórz pokój; następnie sprawdź, czy pokój się otwiera.
Następnie otwórz link do pokoju w osobnej, nieuwierzytelnionej sesji przeglądarki. Z włączonym dostępem dla gości, gość powinien móc dołączyć do konferencji po jej uruchomieniu przez uwierzytelnionego gospodarza. W przewodniku Jitsiego po Dockerze czytamy, że nieuwierzytelnieni użytkownicy muszą poczekać na uwierzytelnienie użytkownika, gdy dostęp dla gości jest włączony.
Aktualny podręcznik samodzielnego hostingu Jitsi oferuje nowszą ścieżkę uwierzytelniania z wykorzystaniem uwierzytelniania tokenowego. Udokumentowany przykład łączy Jitsi z Keycloak, konfiguruje host Prosody tak, aby wymagał tokena, i dodaje anonimową domenę gościa, gdy goście powinni być dozwoleni. W konfiguracji Jitsi, udokumentowana konfiguracja używa authentication = "token"i allow_empty_token = falsedla hosta głównego, a następnie mapuje domenę gościa jako jitsi-anonymous. Postępuj zgodnie z pełnym przewodnikiem uwierzytelniania dla domeny Keycloak, adresów URL przekierowań klienta, routingu odwrotnego proxy, Prosody i ustawień klienta internetowego Jitsi. Zastąp każdą przykładową nazwę hosta własną i zachowaj ochronę punktu końcowego dostawcy tożsamości przez HTTPS.
Uwierzytelnianie tokenowe jest przydatne, gdy konta powinny być zarządzane przez dostawcę tożsamości lub gdy aplikacja wydaje tokeny dostępu specyficzne dla danego pokoju. Wymaga ono poprawnie skonfigurowanego wystawcy i weryfikacji tokena; samo włączenie ustawień przeglądarki nie ogranicza bezpiecznego tworzenia pokoju. Jeśli potrzebujesz kont obsługiwanych przez LDAP z Dockerem, przewodnik po Dockerze opisuje również tryb LDAP, ale ustawienia połączenia LDAP, certyfikatu i filtrów muszą być zgodne z Twoim katalogiem.
Uwierzytelnianie odpowiada na pytanie „kto może rozpocząć konferencję?”. Samo w sobie nie odpowiada na pytanie „kto może wejść do tego pokoju?”. Jeśli goście mają do tego dostęp, każdy, kto uzyska adres URL pokoju, może spróbować dołączyć. Dodaj hasło do pokoju lub skonfiguruj lobby dla spotkań, do których powinni wstępować tylko zaproszeni uczestnicy. Poradnik samodzielnego hostingu Jitsi odróżnia możliwość rozpoczynania konferencji na poziomie serwera od kontroli dostępu zarządzanej w poszczególnych pokojach.
ENABLE_AUTH=1jest aktywna w pliku środowiskowym używanym przez uruchomiony projekt Compose, a następnie ponownie zastosuj konfigurację.ENABLE_GUESTSjest wyłączony. To ustawienie wymaga uwierzytelnienia uczestników; nie jest potrzebne, gdy celem jest uwierzytelnienie gospodarzy z udziałem gości.meet.jitsi; niestandardowe domeny XMPP wymagają odpowiednich wartości.ENABLE_GUESTSustawieniu.Kluczową decyzją jest to, czy Twoja instancja Jitsi powinna korzystać z indywidualnie konfigurowanych kont wewnętrznych, czy z tokenów wydanych przez dostawcę tożsamości. W przypadku istniejącego wdrożenia Docker Compose uwierzytelnianie wewnętrzne to bezpośredni sposób na ograniczenie tworzenia pokoi do niewielkiej grupy zarejestrowanych użytkowników. W przypadku nowej instalacji należy rozpocząć od aktualnego przewodnika uwierzytelniania tokenów i osobno skonfigurować kontrolę dostępu na poziomie pokoju.
Porównaj 10 narzędzi do pingowania, które umożliwiają szybkie wykrywanie sieci LAN, skanowanie międzyplatformowe i zarządzanie adresami IP. Dowiedz się, co narzędzie pingujące może Ci powiedzieć, a czego nie.
Porównaj sześć narzędzi do zarządzania siecią służących do monitorowania wydajności, obejmujących zasięg SNMP, mapowanie, alerty, modele wdrażania i kompromisy kosztów.
Porównaj siedem darmowych i otwartych monitorów pingów — od kompletnych pakietów sieciowych po ukierunkowane sondy opóźnień — i wybierz odpowiedni monitor pod kątem dostępności, utraty pakietów i historii.
Dowiedz się, co oznacza QoS w sieciach, w jaki sposób oznaczenia DSCP i kolejki ruchu nadają priorytet aplikacjom głosowym, wideo i biznesowym oraz czego QoS nie jest w stanie naprawić.
Porównaj niezawodne oprogramowanie serwera SFTP dla systemów Windows i Linux, w tym OpenSSH, Bitvise, SolarWinds i SFTPGo. Znajdź rozwiązanie odpowiednie dla swoich potrzeb w zakresie bezpieczeństwa i transferu plików.
Porównaj siedem narzędzi do zarządzania adresami IP służących do wykrywania podsieci, koordynacji DNS i DHCP, inwentaryzacji sieci i otwartego oprogramowania IPAM.
Porównaj sześć narzędzi do monitorowania systemu Windows Server pod kątem zbierania danych systemu Windows, widoczności aplikacji, modelu wdrażania i licencjonowania, aby znaleźć odpowiednie rozwiązanie.
Porównaj narzędzia do skanowania sieciowego umożliwiające szybkie wykrywanie urządzeń, skanowanie adresów IP na wielu platformach oraz zarządzanie IPAM w przedsiębiorstwie. Znajdziesz tu wskazówki dotyczące dopasowania każdej opcji do swojej sieci.
Zbuduj praktyczny monitoring sieci z przejrzystym zakresem urządzeń, przydatnymi wskaźnikami wydajności, przydatnymi alertami oraz porównaniem SolarWinds NPM, PRTG i OpManager.
Użyj opcji --traceroute programu Nmap, aby mapować przeskoki do autoryzowanego hosta, zrozumieć dane wyjściowe dotyczące przeskoków i czasu RTT oraz rozwiązywać problemy z brakującymi odpowiedziami bez nadmiernego skanowania.
