如何將 Jitsi 會議室的建立權限限制為特定已認證用戶

截至 2026 年 10 月 6 日，Jitsi 目前的自架手冊仍支援僅允許已認證使用者建立會議室，並允許訪客隨後加入的目標。但是，該手冊現在已將舊的「安全域」流程標記為已棄用，並建議改用基於令牌的身份驗證。正確的設定取決於您安裝 Jitsi 的方式：本指南為 Docker 部署提供了直接的內部身分驗證路徑，並解釋了新的 Debian 或 Ubuntu 安裝的當前方向。

這些控制措施決定了誰可以創建房間。它們不會自動將所有房間設為私密房間。房間密碼、大廳和邀請流程是獨立的控制措施。

選擇身份驗證路徑

部署	務實的選擇	它控制著什麼
官方 Docker Compose 部署	在 Prosody 中啟用內部身份驗證並配置帳戶	只有您建立的帳戶才能發起會議；訪客加入功能可設定。
新的 Debian 或 Ubuntu 部署	請遵循 Jitsi 目前的令牌認證指南，該指南在其文件範例中使用了 Keycloak。	只有從您的身份驗證流程中收到有效令牌的使用者才能發起會議。
現有安裝使用舊的安全域設置	僅在規劃升級時保留為舊版配置。	較早的已認證主機和匿名訪客拆分

目前的Jitsi 驗證指南描述如何建立允許匿名訪客參與的已認證房間，而舊版的 Secure Domain 頁面明確指出，該方法已棄用，不適用於新安裝。請勿在未查閱與您的安裝方法相符的指南的情況下，將舊的 Prosody 或 Jicofo 設定複製到新的部署環境中。

Docker：僅允許已設定的使用者啟動房間

此流程假設您已透過官方 Docker Compose 專案執行 Jitsi Meet，並且可以編輯其設定.env檔。以下範例使用內建internal身份驗證模式。它不會添加公共註冊頁面：管理員負責建立和刪除已授權的帳戶。

1. 在環境文件中啟用身份驗證

開啟.envJitsi Compose 部署使用的檔案。如下設定身份驗證變數：

暗黑組態編輯器會在 Jitsi .env 檔案中顯示 ENABLE_AUTH=1、ENABLE_GUESTS=1 和 AUTH_TYPE=internal。 — Docker 環境變數用於啟用身份驗證、允許訪客存取和選擇內部帳戶。

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

請確保這些行是活動設置，而不是以“.”開頭的註解#。ENABLE_GUESTS=1啟用「.」後，未登入的使用者可以在已驗證使用者開啟會議後以訪客身分加入。如果您希望所有參與者都進行身份驗證，請設定「.」ENABLE_GUESTS=0；這將更改誰可以加入會議，而不僅僅是誰可以創建房間。

Docker 指南記錄了這些變數和內建帳戶工作流程。請參閱其「Docker 身份驗證」部分，以了解目前支援的身份驗證類型和選項清單。

2. 應用程式配置

從包含 Compose 檔案的目錄中，套用更新後的環境變數。 Compose 將重新建立配置已變更的服務：

docker compose up -d

建立帳戶前，請檢查容器是否正在運作。如果您使用自訂的 Compose 專案、不同的專案名稱或編排層，請針對該部署執行對應的更新，而不是啟動第二個 Jitsi 堆疊。

3. 為每位已批准的房間管理員建立帳戶

在 Prosody 容器中開啟一個 shell：

docker compose exec prosody /bin/bash

然後，在預設的 Docker XMPP 網域上註冊一個 Jitsi 使用者：

終端機視窗顯示使用 Docker 設定路徑和 meet.jitsi 上的範例帳號 host1 的 Prosody 帳號註冊指令。 — account-registration 指令用於建立內部使用者；執行該指令時，請提供所選的使用者名稱和密碼。

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

帳戶清單應僅限於有權發起會議的人員。房間名稱並非存取控制機制，主持人不再需要該帳戶時，應將其移除。

4. 分別測試主機路徑和客戶機路徑。

使用隱私瀏覽視窗或單獨的瀏覽器設定文件，以免現有的 Jitsi 登入會話遮擋結果。開啟 Jitsi 公用 URL，嘗試在不進行身份驗證的情況下建立一個新房間。 Jitsi 實例應該會在指派新會議之前要求進行身份驗證。使用您建立的帳戶之一登入並建立一個房間；然後驗證房間是否已開啟。

一個簡單的會議登入面板，包含使用者名稱和密碼字段，並說明需要登入才能以主持人身份建立會議。 — 通用登入畫面展示了在獲得批准的主持人創建房間之前應該出現的身份驗證介面。

接下來，在另一個未經身份驗證的瀏覽器會話中開啟會議室連結。啟用訪客存取權限後，訪客應該能夠在已驗證身分的主持人發起會議後加入會議。 Jitsi 的 Docker 指南指出，啟用訪客存取權限後，未經身份驗證的使用者需要等待其他使用者通過身份驗證才能加入會議。

會議等待介面顯示與會者正在等待主持人，會議尚未開始。 — 等待已驗證身份的房主的訪客演示了創建房間和訪客加入房間之間的差異。

對於新安裝的 Debian 或 Ubuntu 系統，請使用最新的令牌身份驗證指南。

Jitsi 目前的自架服務手冊提供了一種使用令牌認證的新型認證方式。其範例文件將 Jitsi 連接到 Keycloak，配置 Prosody 主機以要求提供令牌，並在允許訪客訪問時新增匿名訪客網域。在 Jitsi 設定中，文件中的設定使用 `<hostname>`authentication = "token"和allow_empty_token = false`<hostname>` 作為主主機，然後將訪客網域對應為 `<hostname> jitsi-anonymous`。請依照完整的驗證指南設定 Keycloak 網域、用戶端重新導向 URL、反向代理路由、Prosody 和 Jitsi Web 用戶端設定。請將所有範例主機名稱替換為您自己的主機名，並確保身分提供者端點受到 HTTPS 保護。

當帳戶需要由身分提供者管理，或者您的應用程式需要頒發特定於房間的存取權杖時，令牌身份驗證非常有用。它需要正確配置頒發者和令牌驗證；僅啟用瀏覽器設定並不能安全地限制房間的建立。如果您需要使用 Docker 的 LDAP 帳戶，Docker 指南中也介紹了 LDAP 模式，但 LDAP 連線、憑證和篩選器設定必須與您的目錄相符。

房間創建與房間隱私是分開的

身份驗證回答了「誰可以發起會議？」這個問題，但它本身並不能回答「誰可以進入這個會議室？」這個問題。如果允許訪客加入，任何獲得會議室 URL 的人都可能嘗試加入會議。因此，需要為會議添加密碼，或配置會議大廳，使其僅允許受邀參與者進入。 Jitsi 的自託管指南區分了伺服器層級的會議發起功能和單一會議室的存取控制。

常見問題檢查

房間建立仍然可以匿名進行：確認ENABLE_AUTH=1正在運行的 Compose 項目使用的環境文件中已啟用該功能，然後重新套用配置。
每位參與者都會收到登入提示：請檢查該設定是否ENABLE_GUESTS已停用。此設定要求參與者進行身份驗證；如果您的目標是僅允許已驗證身分的主持人與來賓互動，則無需啟用此功能。
新帳戶無法登入：請確認您已在部署配置的網域上註冊了該帳戶。 Docker 的預設指令使用 `<domain> meet.jitsi`；自訂 XMPP 網域需要對應的值。
訪客必須先進入房間才能進入：這符合訪客訪問規則。請已通過身份驗證的房主先建立房間，然後邀請訪客使用房間連結。
參考其他安裝類型的教學：不要混用 Debian 軟體包路徑、Docker 產生的設定和舊版安全域程式碼片段。請參考手冊中的安裝章節，並仔細閱讀其中的棄用說明。