วิธีจำกัดการสร้างห้อง Jitsi ให้เฉพาะผู้ใช้ที่เข้าสู่ระบบแล้วเท่านั้น

ณ วันที่ 6 ตุลาคม 2569 คู่มือการใช้งาน Jitsi เวอร์ชันปัจจุบันยังคงสนับสนุนเป้าหมายในการอนุญาตให้เฉพาะผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์เท่านั้นสร้างห้องประชุมได้ ในขณะที่อนุญาตให้แขกเข้าร่วมได้ในภายหลัง อย่างไรก็ตาม คู่มือฉบับนี้ระบุว่าขั้นตอน "โดเมนที่ปลอดภัย" แบบเก่าไม่เหมาะสำหรับการติดตั้งใหม่ และแนะนำให้ใช้การตรวจสอบสิทธิ์แบบใช้โทเค็นแทน การตั้งค่าที่ถูกต้องขึ้นอยู่กับวิธีการติดตั้ง Jitsi ของคุณ คู่มือนี้ให้เส้นทางการตรวจสอบสิทธิ์ภายในโดยตรงสำหรับการใช้งาน Docker และอธิบายแนวทางปัจจุบันสำหรับการติดตั้ง Debian หรือ Ubuntu ใหม่

การควบคุมเหล่านี้กำหนดว่าใครสามารถสร้างห้องได้ ไม่ได้หมายความว่าทุกห้องจะเป็นส่วนตัวโดยอัตโนมัติ รหัสผ่านห้อง พื้นที่รอเข้าห้อง และกระบวนการเชิญนั้นเป็นการควบคุมที่แยกต่างหาก

เลือกเส้นทางการตรวจสอบสิทธิ์

คู่มือการตรวจสอบสิทธิ์ของ Jitsiฉบับปัจจุบันอธิบายถึงการสร้างห้องประชุมที่ต้องมีการตรวจสอบสิทธิ์สำหรับแขกที่ไม่ระบุตัวตน และหน้า Secure Domain ฉบับเก่าระบุไว้อย่างชัดเจนว่าวิธีการดังกล่าวไม่เหมาะสำหรับการติดตั้งใหม่ หลีกเลี่ยงการคัดลอกการตั้งค่า Prosody หรือ Jicofo เก่าไปยังการติดตั้งใหม่โดยไม่ตรวจสอบคู่มือที่ตรงกับวิธีการติดตั้งของคุณ

Docker: อนุญาตเฉพาะผู้ใช้ที่ได้รับอนุญาตเท่านั้นให้เริ่มห้องสนทนาได้

ขั้นตอนนี้นั้นสมมติว่าคุณได้ใช้งาน Jitsi Meet จากโปรเจกต์ Docker Compose อย่างเป็นทางการแล้ว และสามารถแก้ไข.envไฟล์ได้ ตัวอย่างด้านล่างใช้โหมดการตรวจสอบสิทธิ์แบบในตัวinternalซึ่งไม่ได้เพิ่มหน้าลงทะเบียนสาธารณะ: ผู้ดูแลระบบจะเป็นผู้สร้างและลบบัญชีผู้ใช้ที่ได้รับอนุญาต

1. เปิดใช้งานการตรวจสอบสิทธิ์ในไฟล์สภาพแวดล้อม

เปิด.envไฟล์ที่ใช้ในการติดตั้ง Jitsi Compose ของคุณ ตั้งค่าตัวแปรการตรวจสอบสิทธิ์ดังนี้:

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:

docker compose exec prosody /bin/bash

จากนั้นลงทะเบียนผู้ใช้ Jitsi ในโดเมน XMPP เริ่มต้นของ Docker:

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 ที่มีอยู่บดบังผลลัพธ์ เปิด URL สาธารณะของ Jitsi แล้วลองเริ่มห้องใหม่โดยไม่ต้องยืนยันตัวตน ระบบควรจะต้องมีการยืนยันตัวตนก่อนที่จะจัดสรรการประชุมใหม่ เข้าสู่ระบบด้วยบัญชีใดบัญชีหนึ่งที่คุณสร้างไว้ แล้วเริ่มห้อง จากนั้นตรวจสอบว่าห้องเปิดขึ้นหรือไม่

ถัดไป เปิดลิงก์ห้องประชุมในเซสชันเบราว์เซอร์ที่ไม่ต้องลงชื่อเข้าใช้แยกต่างหาก เมื่อเปิดใช้งานการเข้าถึงแบบแขกแล้ว แขกจะสามารถเข้าร่วมการประชุมได้หลังจากที่โฮสต์ที่ลงชื่อเข้าใช้เริ่มการประชุมแล้ว คู่มือ Docker ของ Jitsi ระบุว่า ผู้ใช้ที่ไม่ได้รับการลงชื่อเข้าใช้จะต้องรอจนกว่าผู้ใช้จะลงชื่อเข้าใช้เมื่อเปิดใช้งานการเข้าถึงแบบแขก

สำหรับการติดตั้ง Debian หรือ Ubuntu ใหม่ โปรดใช้คู่มือการตรวจสอบสิทธิ์ด้วยโทเค็นฉบับปัจจุบัน

คู่มือการโฮสต์ด้วยตนเองฉบับปัจจุบันของ 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ได้ปิดใช้งานไว้หรือไม่ การตั้งค่านี้กำหนดให้ผู้เข้าร่วมต้องยืนยันตัวตน ซึ่งไม่จำเป็นหากเป้าหมายของคุณคือโฮสต์ที่ยืนยันตัวตนแล้วและผู้เข้าร่วมที่เป็นแขก
• ไม่สามารถเข้าสู่ระบบด้วยบัญชีใหม่ได้:โปรดตรวจสอบว่าคุณได้ลงทะเบียนบัญชีนั้นในโดเมนที่กำหนดค่าไว้สำหรับการใช้งานของคุณแล้ว คำสั่งเริ่มต้นของ Docker จะใช้meet.jitsiค่า ; โดเมน XMPP ที่กำหนดเองจะต้องใช้ค่าที่สอดคล้องกัน
• แขกไม่สามารถเข้าห้องได้ก่อนโฮสต์:นี่เป็นไปตามพฤติกรรมการเข้าใช้งานของแขก โฮสต์ที่ได้รับการยืนยันตัวตนแล้วควรเริ่มห้องก่อน จากนั้นจึงขอให้แขกใช้ลิงก์ห้อง
• ปฏิบัติตามคำแนะนำจากวิธีการติดตั้งแบบอื่น:ห้ามผสมผสานเส้นทางแพ็กเกจ Debian, การกำหนดค่าที่สร้างโดย Docker และส่วนย่อย secure-domain รุ่นเก่า ให้ใช้ส่วนในคู่มือสำหรับการติดตั้งของคุณและตรวจสอบหมายเหตุเกี่ยวกับการเลิกใช้งาน

รายการตรวจสอบการยืนยัน

1. เบราว์เซอร์ที่ไม่ได้รับการตรวจสอบสิทธิ์จะไม่สามารถสร้างห้องใหม่ได้
2. ผู้ใช้ที่ได้รับอนุญาตสามารถเข้าสู่ระบบและเริ่มห้องสนทนาได้
3. บัญชีที่ถูกลบไปแล้วจะไม่สามารถยืนยันตัวตนได้อีกต่อไป
4. การเข้าร่วมของแขกเป็นไปตามที่ตั้งใจไว้สำหรับENABLE_GUESTSการตั้งค่า ของคุณ
5. การประชุมส่วนตัวอาจใช้รหัสผ่านห้องหรือนโยบายบริเวณล็อบบี้หากจำเป็น

ประเด็นสำคัญคือ Jitsi ของคุณควรใช้บัญชีภายในที่จัดเตรียมไว้เฉพาะบุคคล หรือใช้โทเค็นที่ออกผ่านผู้ให้บริการยืนยันตัวตน สำหรับการใช้งาน Docker Compose ที่มีอยู่แล้ว การตรวจสอบสิทธิ์ภายในเป็นวิธีโดยตรงในการจำกัดการสร้างห้องให้เฉพาะกลุ่มผู้ใช้จำนวนน้อยที่คุณลงทะเบียนไว้ สำหรับการติดตั้งใหม่ ให้เริ่มต้นด้วยคู่มือการตรวจสอบสิทธิ์ด้วยโทเค็นฉบับปัจจุบัน และกำหนดค่าการควบคุมการเข้าถึงระดับห้องแยกต่างหาก

เอกสารอ้างอิงอย่างเป็นทางการ

• Jitsi Meet: การยืนยันตัวตน (คู่มือฉบับปัจจุบัน; อัปเดตล่าสุด 5 ตุลาคม 2026)
• คู่มือการโฮสต์ Jitsi Meet ด้วยตนเอง — Docker
• Jitsi Meet: การตั้งค่าโดเมนที่ปลอดภัย (ระบุว่าเลิกใช้แล้วสำหรับการติดตั้งใหม่)
• คู่มือการติดตั้ง Jitsi Meet ด้วยตนเอง — Debian/Ubuntu