Cum să restricționezi crearea de Jitsi Room la anumiți utilizatori autentificați

Începând cu 6 octombrie 2026, manualul actual de auto-găzduire Jitsi susține în continuare obiectivul de a permite doar utilizatorilor autentificați să creeze săli de conferință, permițând în același timp invitaților să se alăture ulterior. Cu toate acestea, manualul marchează acum procedura mai veche „Domeniu securizat” ca fiind depreciată pentru instalările noi și recomandă în schimb autentificarea bazată pe token-uri. Configurarea corectă depinde de modul în care ați instalat Jitsi: acest ghid oferă o cale directă de autentificare internă pentru implementările Docker și explică direcția actuală pentru noile instalări Debian sau Ubuntu.

Aceste controale guvernează cine poate crea o cameră. Nu fac automat fiecare cameră privată. Parolele camerelor, lobby-ul și procesul de invitare sunt controale separate.

Alegeți o cale de autentificare

Ghidul actual de autentificare Jitsi descrie crearea autentificată a camerelor cu invitați anonimi, iar pagina mai veche Secure Domain precizează explicit că această metodă este depreciată pentru instalările noi. Evitați copierea setărilor vechi Prosody sau Jicofo într-o implementare mai nouă fără a verifica ghidul care corespunde metodei dvs. de instalare.

Docker: permite doar utilizatorilor alocați acces să pornească camere

Această procedură presupune că deja rulați Jitsi Meet din proiectul oficial Docker Compose și că puteți edita .envfișierul acestuia. Exemplul de mai jos folosește modul de autentificare încorporat internal. Nu adaugă o pagină publică de înscriere: un administrator creează și elimină conturile permise.

1. Activați autentificarea în fișierul de mediu

Deschideți .envfișierul utilizat de implementarea Jitsi Compose. Setați variabilele de autentificare astfel:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Asigurați-vă că liniile sunt setări active și nu comentarii care încep cu #. Cu ENABLE_GUESTS=1, persoanele care nu sunt conectate se pot alătura ca invitați după ce un utilizator autentificat a deschis conferința. Dacă doriți ca fiecare participant să se autentifice, setați ENABLE_GUESTS=0; care modifică cine se poate alătura, nu doar cine poate crea camere.

Ghidul Docker documentează aceste variabile și fluxul de lucru încorporat în cont. Consultați secțiunea Autentificare pentru Docker pentru lista actuală a tipurilor și opțiunilor de autentificare acceptate.

2. Aplicați configurația

Din directorul care conține fișierul Compose, aplicați mediul actualizat. Compose va recrea serviciile a căror configurație s-a modificat:

docker compose up -d

Verificați dacă containerele rulează înainte de a crea conturi. Dacă utilizați un proiect Compose personalizat, un nume de proiect diferit sau un strat de orchestrare, rulați actualizarea echivalentă pentru acea implementare în loc să începeți o a doua stivă Jitsi.

3. Creați un cont pentru fiecare gazdă de cameră aprobată

Deschideți o shell în containerul Prosody:

docker compose exec prosody /bin/bash

Apoi înregistrează un utilizator Jitsi pe domeniul XMPP implicit Docker:

prosodyctl --config /run/prosody/config/prosody.cfg.lua register <username> meet.jitsi <strong-password>

Înlocuiți ambele titluri substituibile cu numele de utilizator și o parolă unică pentru acea persoană. Nu includeți parantezele unghiulare. Pentru o a doua gazdă autorizată, rulați din nou comanda cu un nume de utilizator diferit. Comanda afișată utilizează domeniul Docker implicit meet.jitsi; dacă l-ați modificat XMPP_DOMAIN, urmați domeniul configurat de implementare. Ghidul Docker actual documentează comanda containerului Prosody și comanda de eliminare aferentă.

Pentru a revoca un utilizator, intrați în containerul Prosody și executați:

prosodyctl --config /run/prosody/config/prosody.cfg.lua unregister <username> meet.jitsi

Păstrați lista de conturi limitată la persoanele care ar trebui să poată iniția conferințe. Numele unei săli nu este un mecanism de control al accesului, iar accesul la cont ar trebui eliminat atunci când o gazdă nu mai are nevoie de el.

4. Testați separat căile gazdă și invitat

Folosește o fereastră privată de browser sau un profil separat de browser, astfel încât o sesiune de conectare Jitsi existentă să nu ascundă rezultatul. Deschide adresa URL publică Jitsi și încearcă să începi o cameră nouă fără autentificare. Instanța ar trebui să necesite autentificare înainte de a aloca noua conferință. Conectează-te cu unul dintre conturile pe care le-ai creat și începe o cameră; apoi verifică dacă se deschide camera.

Apoi, deschideți linkul camerei într-o sesiune separată de browser, neautentificată. Cu accesul invitatului activat, invitatul ar trebui să poată participa la conferință după ce gazda autentificată o pornește. Ghidul Docker al Jitsi precizează că utilizatorii neautentificați trebuie să aștepte până când un utilizator se autentifică atunci când accesul invitatului este activat.

Pentru instalări noi de Debian sau Ubuntu, utilizați ghidul curent de autentificare cu token-uri.

Manualul actual de auto-găzduire Jitsi oferă o cale de autentificare mai nouă folosind autentificarea cu token-uri. Exemplul său documentat conectează Jitsi la Keycloak, configurează gazda Prosody să solicite un token și adaugă un domeniu anonim pentru oaspeți atunci când accesul oaspeților ar trebui să fie permis. În configurația Jitsi, configurația documentată utilizează authentication = "token"și allow_empty_token = falsepentru gazda principală, apoi mapează domeniul pentru oaspeți ca jitsi-anonymous. Urmați ghidul complet de autentificare pentru domeniul Keycloak, URL-urile de redirecționare ale clienților, rutarea reverse-proxy, Prosody și setările clientului web Jitsi. Înlocuiți fiecare nume de gazdă exemplu cu al dvs. și păstrați endpoint-ul furnizorului de identitate protejat prin HTTPS.

Autentificarea prin token este utilă atunci când conturile trebuie gestionate de un furnizor de identitate sau când aplicația dvs. emite tokenuri de acces specifice camerei. Necesită un emitent configurat corect și o validare a tokenului; simpla activare a unei setări de browser nu restricționează crearea de camere în siguranță. Dacă aveți nevoie de conturi bazate pe LDAP cu Docker, ghidul Docker documentează și un mod LDAP, dar setările conexiunii LDAP, certificatului și filtrului trebuie să corespundă directorului dvs.

Crearea camerei este separată de intimitatea camerei

Autentificarea răspunde la întrebarea „cine poate începe o conferință?”. Nu răspunde singură la întrebarea „cine poate intra în această cameră?”. Dacă sunt permise accesul invitaților, oricine obține adresa URL a camerei poate încerca să se alăture. Adăugați o parolă pentru cameră sau configurați sala de așteptare pentru întâlniri care ar trebui să admită doar participanți invitați. Ghidul de auto-găzduire Jitsi distinge capacitatea la nivel de server de a începe conferințe de controalele de acces gestionate într-o cameră individuală.

Probleme frecvente de verificat

• Crearea camerelor funcționează în continuare anonim: confirmați ENABLE_AUTH=1dacă este activă în fișierul de mediu utilizat de proiectul Compose care rulează, apoi reaplicați configurația.
• Fiecare participant primește o solicitare de conectare: verificați dacă ENABLE_GUESTSeste dezactivată. Această setare necesită autentificarea participanților; nu este necesară atunci când obiectivul dvs. este autentificarea gazdelor cu participanți invitați.
• Un cont nou nu se poate conecta: verificați dacă l-ați înregistrat pe domeniul configurat pentru implementarea dvs. Comanda implicită a Docker folosește meet.jitsi; domeniile XMPP personalizate necesită valori corespunzătoare.
• Oaspeții nu pot intra înaintea gazdei: acest lucru este în concordanță cu comportamentul de acces al oaspeților. Gazda autentificată trebuie să înceapă mai întâi camera, apoi să le ceară oaspeților să folosească linkul către cameră.
• Urmărind un tutorial dintr-un alt tip de instalare: nu amestecați căile de pachete Debian, configurația generată de Docker și fragmentele de cod de domeniu securizat mai vechi. Folosiți secțiunea manualului pentru instalare și consultați notele de depreciere.

Listă de verificare

1. Un browser neautentificat nu poate crea o cameră nouă.
2. Un utilizator configurat se poate conecta și poate crea o sală.
3. Un cont eliminat nu se mai poate autentifica.
4. Înscrierea ca invitat se comportă conform ENABLE_GUESTSsetărilor tale.
5. Întâlnirile private folosesc și o parolă pentru sală sau o politică de lobby, acolo unde este necesar.

Decizia cheie este dacă instanța Jitsi ar trebui să utilizeze conturi interne furnizate individual sau token-uri emise printr-un furnizor de identitate. Pentru o implementare Docker Compose existentă, autentificarea internă este o modalitate directă de a restricționa crearea de camere la setul mic de utilizatori pe care îi înregistrați. Pentru o instalare nouă, începeți cu ghidul curent de autentificare a token-urilor și păstrați configurate separat controalele de admitere la nivel de cameră.

Referințe oficiale

• Jitsi Meet: Autentificare (ghid actual; ultima actualizare 5 octombrie 2026)
• Jitsi Meet: Ghid de auto-găzduire — Docker
• Jitsi Meet: Configurare securizată a domeniului (marcat ca depreciat pentru instalările noi)
• Jitsi Meet: Ghid de auto-găzduire — Debian/Ubuntu