แก้ไขปัญหาข้อความ "M_FORBIDDEN: คุณไม่มีสิทธิ์" ในหน้าผู้ดูแลระบบ Matrix Room

คุณพยายามเปลี่ยนการตั้งค่าห้อง Matrix ลบผู้ใช้ แบนใครบางคน แก้ไขสิทธิ์ หรือดำเนินการด้านการดูแลระบบอื่นๆ แล้วได้รับM_FORBIDDEN: You do not have permissionข้อความนี้ สำหรับผู้ใช้ใหม่ ข้อความนี้อาจทำให้สับสนได้ เพราะ "admin" ใน Matrix อาจหมายถึงสองสิ่งแตกต่างกัน: ผู้ดูแลเซิร์ฟเวอร์ควบคุมโฮมเซิร์ฟเวอร์ ในขณะที่ผู้ดูแลห้องมีอำนาจเพียงพอภายในห้องใดห้องหนึ่งโดยเฉพาะ ระบบการอนุญาตเหล่านี้แยกจากกัน

วิธีแก้ไขที่ได้ผลคือการระบุว่าเลเยอร์การอนุญาตใดที่บล็อกการกระทำนั้นก่อนที่จะเปลี่ยนแปลงอะไร การอนุญาตห้องใน Matrix ขึ้นอยู่กับระดับอำนาจ : ตัวเลขที่จัดเก็บไว้ในสถานะห้องซึ่งกำหนดว่าใครสามารถเชิญ ไล่ แบน แก้ไขข้อความ เปลี่ยนการตั้งค่าห้อง หรือแก้ไขระดับอำนาจได้ ข้อกำหนด Matrix ปัจจุบันกำหนดกฎเหล่านั้นไว้ในข้อกำหนด Matrix Client-Server API Synapse ได้ระบุไว้แยกต่างหากว่าผู้ดูแลระบบเซิร์ฟเวอร์แตกต่างจากผู้ดูแลระบบห้องในเอกสาร Synapse Admin API

ก่อนที่คุณจะเปลี่ยนแปลงอะไรก็ตาม โปรดทำความเข้าใจคุณค่าทั้งสี่ประการที่สำคัญเสียก่อน

โดยปกติคุณจะต้องมีข้อมูลสี่ส่วนดังนี้:

• ตัวอย่างเช่น@alice:example.comรหัสผู้ใช้ Matrix ของคุณ
• ตัวอย่างเช่นรหัสห้อง!abc123:example.comชื่อเรียกแทนห้อง เช่น นั้น#team:example.comอ่านง่ายกว่า แต่ API หลายตัวทำงานโดยใช้รหัสห้องภายใน
• สถานะสมาชิกของคุณในกรณีส่วนใหญ่ คุณต้องเข้าร่วมห้องก่อนจึงจะสามารถดำเนินการจัดการห้องได้
• ระดับพลังของคุณและระดับที่จำเป็นสำหรับการกระทำนั้น

ใน Element เวอร์ชันเว็บหรือเดสก์ท็อป คุณสามารถค้นหารหัสห้องและเวอร์ชันห้องได้ใน การตั้งค่าห้อง ภายใต้ ขั้นสูง เอกสารประกอบการใช้งานปัจจุบันของ Element ยังระบุการจัดการห้องไว้ที่การตั้งค่าห้อง → บทบาทและสิทธิ์ โปรดดูคู่มือการตั้งค่าห้องของ Element

ขั้นตอนที่ 1: ตรวจสอบให้แน่ใจว่าคุณได้เข้าร่วมห้องสนทนาแล้ว

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

หากคุณใช้ไคลเอ็นต์ Matrix เช่น Element ให้เปิดห้องและยืนยันว่าห้องนั้นปรากฏเป็นห้องที่ใช้งานอยู่ซึ่งคุณได้เข้าร่วมแล้ว ไม่ใช่แค่คำเชิญหรือห้องที่เคยเข้าชมมาก่อน หากคุณใช้งาน Synapse และต้องการเส้นทางการกู้คืนในฐานะผู้ดูแลระบบเซิร์ฟเวอร์ Synapse มีเอนด์พอยต์สำหรับผู้ดูแลระบบในการเพิ่มผู้ใช้ภายในเครื่องเข้าสู่ห้อง แต่ Synapse ยังคงระบุข้อกำหนดด้านสิทธิ์ในการดำเนินการดังกล่าวไว้ โปรดดูที่ การจัดการสมาชิกห้อง ในSynapse

โปรดหลีกเลี่ยงข้อผิดพลาดนี้:อย่าคิดว่าการมีโทเค็น Synapse Admin API จะทำให้ได้รับสิทธิ์ระดับห้องโดยอัตโนมัติ การดูแลระบบเซิร์ฟเวอร์และการดูแลระบบห้องนั้นแตกต่างกันโดยเจตนา

ขั้นตอนที่ 2: ตรวจสอบบทบาทของคุณและระดับพลังที่จำเป็นสำหรับการกระทำนั้น

Element นำเสนอระดับอำนาจทั่วไปในรูปแบบบทบาทที่คุ้นเคย เช่น สมาชิก ผู้ดูแล และผู้ดูแลระบบ แต่ในเชิงลึกแล้ว Matrix จะประเมินค่าเป็นตัวเลขมากกว่าป้ายกำกับ ข้อกำหนดของ Matrix แนะนำให้ตีความตามแบบที่คุ้นเคย คือ ผู้ใช้ทั่วไปอยู่ต่ำกว่าเกณฑ์สถานะ/เหตุการณ์ ผู้ดูแลอยู่เหนือเกณฑ์นั้น และผู้ดูแลระบบอยู่ที่ระดับที่สูงกว่าหรือเท่ากับระดับที่จำเป็นในการแก้ไขm.room.power_levelsโดยทั่วไปห้องสนทนาจะใช้ค่า 0 สำหรับสมาชิก 50 สำหรับผู้ดูแล และ 100 สำหรับผู้ดูแลระบบ แต่ห้องสนทนาสามารถปรับแต่งค่าเหล่านั้นได้

ไปที่ การตั้งค่าห้อง → บทบาทและสิทธิ์ตรวจสอบทั้งบทบาทของคุณและการกระทำที่คุณต้องการทำ เอกสารปัจจุบันของ Element ระบุการกระทำทั่วไป เช่น การเปลี่ยนการตั้งค่า การลบผู้ใช้ การแบนผู้ใช้ การเปลี่ยนการมองเห็นประวัติ และการเปลี่ยนสิทธิ์ ซึ่งแต่ละการกระทำจะมีระดับพลังที่จำเป็นแตกต่างกัน

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

ขั้นตอนที่ 3: ตรวจสอบผู้ใช้เป้าหมายและกำลังส่งของคุณเอง

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

ตัวอย่าง: บัญชีของคุณมีเลเวล 50 เกณฑ์ของห้องkickคือ 50 และผู้ดูแลห้องอีกคนก็มีเลเวล 50 เช่นกัน คุณมีเลเวลถึงเกณฑ์การเตะแล้ว แต่คุณยังไม่สามารถเตะผู้ดูแลห้องที่มีเลเวลเท่ากันได้ กฎการอนุญาตปฏิเสธการดำเนินการเนื่องจากเป้าหมายไม่ได้มีเลเวลต่ำกว่าคุณ

หลักการเดียวกันนี้อธิบายถึงความล้มเหลวในการดูแลจัดการห้องสนทนาที่สร้างความสับสนมากมาย ผู้ดูแลห้องสนทนาควรตรวจสอบทั้งสองด้านของการเปรียบเทียบ:

• ระดับพลังงานปัจจุบันของคุณ
• ข้อกำหนดkickหรือbanเกณฑ์ขั้นต่ำ
• ระดับพลังงานปัจจุบันของผู้ใช้งานเป้าหมาย

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

ขั้นตอนที่ 4: ใช้ผู้ดูแลห้องประชุมที่มีอยู่แล้ว หากมีผู้ดูแลห้องประชุมว่างอยู่

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

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

หากยังคงล้มเหลว ให้เปรียบเทียบการกระทำที่เกิดขึ้นกับเกณฑ์การอนุญาต แทนที่จะสันนิษฐานว่า "ผู้ดูแลระบบ" หมายความว่าทุกการกระทำได้รับอนุญาตโดยอัตโนมัติ เหตุการณ์ระดับอำนาจแบบกำหนดเองสามารถกำหนดเกณฑ์ที่ผิดปกติให้กับประเภทเหตุการณ์เฉพาะได้

ขั้นตอนที่ 5: หากไม่มีผู้ดูแลระบบห้องที่ใช้งานได้เหลืออยู่ ให้กู้คืนผ่าน Synapse

หากคุณใช้งานโฮมเซิร์ฟเวอร์ Synapse และมีห้องใดห้องหนึ่งไม่มีผู้ดูแลระบบที่ใช้งานอยู่ ให้ใช้ API การกู้คืนที่ Synapse รองรับแทนการแก้ไขฐานข้อมูลหรือสร้างเหตุการณ์ห้องใหม่ Synapse มี API สำหรับสร้างผู้ดูแลระบบห้อง (Make Room Admin API) ให้บริการ :

POST /_synapse/admin/v1/rooms/<room_id_or_alias>/make_room_admin

{
  "user_id": "@alice:example.com"
}

ยืนยันคำขอด้วยโทเค็นการเข้าถึงของผู้ดูแลระบบเซิร์ฟเวอร์ Synapse เอกสาร API สำหรับการจัดการห้องอย่างเป็นทางการมีอยู่ที่Synapse Rooms Admin APIปลายทางนี้จะให้สิทธิ์ผู้ใช้ภายในที่เลือกไว้ในการเข้าถึงห้องในระดับสูงสุดที่มีให้สำหรับผู้ใช้ภายในในห้องนั้น หากจำเป็นและเป็นไปได้ ระบบสามารถเชิญผู้ใช้นั้นก่อนได้

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

กรณีพิเศษ: ห้องเวอร์ชัน 12 ขึ้นไป

Matrix Room เวอร์ชัน 12 เปลี่ยนแปลงวิธีการแสดงผู้สร้าง ผู้สร้างมีระดับพลังที่แทบจะไม่มีขีดจำกัดและเปลี่ยนแปลงไม่ได้ และจะไม่ปรากฏอยู่ในusersแผนผัง เหมือนผู้ใช้ทั่วไป m.room.power_levelsผู้สร้างไม่สามารถถูกลดระดับพลังผ่านเหตุการณ์ลดระดับพลังตามปกติ พฤติกรรมนี้ได้รับการบันทึกไว้ในข้อกำหนดของ Matrix Room เวอร์ชัน 12แล้ว

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

วิธีตรวจสอบระดับพลังงานโดยตรง

สำหรับการแก้ไขปัญหาขั้นสูง เหตุการณ์สถานะห้องที่เกี่ยวข้องคือm.room.power_levelsซึ่งประกอบด้วยฟิลด์ต่างๆ เช่น:

{
  "users_default": 0,
  "state_default": 50,
  "invite": 0,
  "kick": 50,
  "ban": 50,
  "redact": 50,
  "users": {
    "@alice:example.com": 100,
    "@bob:example.com": 50
  }
}

หากบัญชีของคุณไม่ปรากฏอยู่ในรายการusersระดับของบัญชีจะถูกลดระดับลงเป็นค่าเริ่มต้นusers_defaultซึ่งสำหรับห้องส่วนใหญ่หมายถึง 0 นอกจากนี้ ประเภทเหตุการณ์เฉพาะยังสามารถแทนที่สถานะทั่วไปหรือเกณฑ์ข้อความผ่านทางeventsแผนที่ได้

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

สิ่งที่ไม่ควรทำ

• อย่าเพิ่มสิทธิ์บัญชี Synapse ให้เป็นผู้ดูแลระบบเซิร์ฟเวอร์เพียงเพื่อแก้ปัญหาบทบาทในห้องสนทนาทั่วไปให้ใช้สิทธิ์ที่จำเป็นน้อยที่สุดเท่านั้น
• ห้ามแก้ไขข้อมูลในฐานข้อมูล Synapse เพื่อเปลี่ยนระดับพลังงานของห้องการอนุญาตใช้งานห้องจะแสดงด้วยเหตุการณ์ห้องที่ลงชื่อแล้ว ไม่ใช่เพียงแค่แฟล็กของผู้ใช้ในฐานข้อมูล
• อย่ารีสตาร์ท Synapse เพื่อแก้ไขปัญหาตามปกติM_FORBIDDENความล้มเหลวในการอนุญาตมักเกิดจากการตัดสินใจสถานะห้องแบบกำหนดได้ ไม่ใช่ปัญหาจากกระบวนการที่ค้างอยู่
• อย่าคิดว่าการล้างแคชของไคลเอ็นต์จะเปลี่ยนสิทธิ์การเข้าถึงได้โฮมเซิร์ฟเวอร์เป็นผู้บังคับใช้กฎการอนุญาต
• อย่าเปิดเผยโทเค็นการเข้าถึงในประวัติการใช้งานเชลล์ ภาพหน้าจอ ตั๋วสนับสนุน หรือ URLควรใช้ส่วนAuthorization: Bearer ...หัวเมื่อใช้งาน API แทน

ตารางการวินิจฉัยอย่างรวดเร็ว

การตรวจสอบขั้นสุดท้าย

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

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