แก้ไขข้อผิดพลาดการตรวจสอบ WOPI โดยตรวจสอบคีย์ การค้นหา และ URL

เมื่อโฮสต์ WOPI รายงานว่า “การตรวจสอบหลักฐานล้มเหลว” หรือ “หลักฐาน WOPI ไม่ถูกต้อง” ให้ตรวจสอบก่อนว่าระบบใดบันทึกการปฏิเสธนั้น หากโฮสต์จัดเก็บข้อมูลปฏิเสธคำขอที่ลงนามของ Collabora ให้ตรวจสอบคู่คีย์หลักฐานและการตอบสนองการค้นหาก่อนที่จะเปลี่ยนแปลงรายการอนุญาตของโฮสต์ WOPI หรือปิดใช้งานการตรวจสอบหลักฐาน สำหรับการติดตั้งแพ็กเกจ Collabora จะสร้างคู่คีย์โดยอัตโนมัติ สำหรับ Docker, Kubernetes และการปรับใช้แบบหลายสำเนา คู่คีย์จะต้องถูกจัดเตรียมและจัดเก็บอย่างสม่ำเสมอ

ระบุการตรวจสอบที่ล้มเหลวก่อนทำการเปลี่ยนคีย์

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

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

เลือกวิธีการซ่อมแซมที่เหมาะสมกับการใช้งาน

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

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

ตรวจสอบและซ่อมแซมกุญแจคู่ได้อย่างปลอดภัย

1. ค้นหาเส้นทางคีย์ที่กำหนดค่าไว้บนโฮสต์ Collabora หรือภายในคอนเทนเนอร์ ตรวจสอบcoolwsd.xmlการตั้งค่าสำหรับเส้นทางคีย์พิสูจน์ และตรวจสอบว่ามีทั้งคีย์ส่วนตัวและคีย์สาธารณะหรือไม่ ตำแหน่งทั่วไปจะอยู่ภายใต้/etc/coolwsd/แต่โครงสร้างของแพ็กเกจและคอนเทนเนอร์อาจแตกต่างกันไป ห้ามวางคีย์ส่วนตัวลงในบันทึก ตั๋ว หรือแชทเด็ดขาด
2. ตรวจสอบว่าคีย์ตรงกันสำหรับเส้นทางเริ่มต้นทั่วไป ให้เปรียบเทียบลายนิ้วมือโดยไม่ต้องแสดงคีย์ส่วนตัว: sudo openssl pkey -in /etc/coolwsd/proof_key -pubout -outform DER | sha256sumและopenssl pkey -pubin -in /etc/coolwsd/proof_key.pub -outform DER | sha256sumแฮชที่ได้ควรตรงกัน หากเส้นทางของคุณแตกต่างกัน ให้แทนที่ด้วยเส้นทางที่กำหนดค่าไว้จริง หากไม่สามารถอ่านคีย์ส่วนตัวได้ ให้แก้ไขความเป็นเจ้าของและสิทธิ์การเข้าถึงตามแบบจำลองความปลอดภัยของบริการ อย่าทำให้ทุกคนสามารถอ่านได้
3. สร้างคีย์ส่วนตัวใหม่เฉพาะเมื่อจำเป็นเท่านั้นหากคีย์ส่วนตัวหายไปหรือคู่คีย์ไม่ตรงกัน ให้ใช้sudo coolconfig generate-proof-keyยูทิลิตี้ที่ติดตั้งไว้ สำหรับ Docker ให้สร้างคู่คีย์ในตำแหน่งถาวรที่เหมาะสม จากนั้นเมานต์ไฟล์ทั้งสองไปยังตำแหน่งที่ Collabora คาดหวัง และตรวจสอบให้แน่ใจว่ากระบวนการ coolwsd สามารถอ่านคีย์ส่วนตัวได้ บนแพลตฟอร์มที่มีการจัดการ ให้ใช้กลไก Secret ที่รองรับแทนการแก้ไข pod ที่กำลังทำงานอยู่ด้วยตนเอง
4. ทำให้ทุกอินสแตนซ์มีความสอดคล้องกันสำหรับสำเนา ให้ปรับใช้คู่คีย์เดียวกันกับแต่ละอินสแตนซ์ แล้วรีสตาร์ทหรือปรับใช้ Collabora เพื่อให้สามารถอ่านไฟล์ได้ จากนั้นรีเฟรชหรือดึงข้อมูลการค้นหา WOPI ใหม่บนโฮสต์จัดเก็บข้อมูลโดยใช้กลไกที่โฮสต์นั้นรองรับ การหมุนเวียนคีย์จะเปลี่ยนคีย์สาธารณะ แคชหรือสำเนาอื่นที่ยังคงให้บริการคีย์เดิมอาจทำให้ความล้มเหลวยังคงอยู่ได้

เมื่อคีย์ตรงกัน แต่การตรวจสอบหลักฐานยังคงล้มเหลว

ตรวจสอบการซิงโครไนซ์เวลาบนทั้งสองระบบ คำขอพิสูจน์ WOPI มีการประทับเวลาอยู่ด้วย โฮสต์อาจปฏิเสธการประทับเวลาที่เก่าหรืออยู่นอกช่วงเวลาที่กำหนด ตรวจสอบให้แน่ใจว่า NTP หรือบริการเวลาของแพลตฟอร์มทำงานได้อย่างปกติ และเซิร์ฟเวอร์รายงานเวลา UTC ที่สมเหตุสมผล อย่าลดความเข้มงวดในการตรวจสอบการประทับเวลาเพื่อแก้ไขปัญหาเรื่องนาฬิกา

ถัดไป ให้ตรวจสอบ URL สาธารณะที่โฮสต์ใช้ในการสร้างคำขอที่ลงนามแล้วขึ้นมาใหม่ หลักฐานนั้นเชื่อมโยงกับ URL ของคำขอ รวมถึงพารามิเตอร์การค้นหาที่เกี่ยวข้อง และข้อกำหนดของ WOPI กำหนดให้การแสดง URL ที่ใช้สำหรับการตรวจสอบความถูกต้องต้องตรงกับรูปแบบที่ลงนามแล้ว พร็อกซีแบบย้อนกลับที่ยุติ HTTPS อาจทำให้แอปพลิเคชันเห็น URL HTTP ภายใน แม้ว่า Collabora จะลงนามใน URL HTTPS สาธารณะแล้วก็ตาม กำหนดค่าส่วนหัวพร็อกซีที่เชื่อถือได้และการตั้งค่า URL ภายนอกของแอปพลิเคชันตามคำแนะนำอย่างเป็นทางการของโฮสต์ WOPI อย่าเขียนตรรกะการพิสูจน์ใหม่หรือลบพารามิเตอร์การค้นหา

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

ตรวจสอบการซ่อมแซม

1. ดึงข้อมูลปลายทางการค้นหา Collabora จากเครือข่ายของโฮสต์จัดเก็บข้อมูล และยืนยันว่าได้ส่งคืนข้อมูลเมตาคีย์พิสูจน์ปัจจุบันแล้ว
2. เปิดเอกสารทดสอบและตรวจสอบว่าโฮสต์จัดเก็บข้อมูลยอมรับคำขอ CheckFileInfo และคำขอเอกสารอื่นๆ ที่ตามมาโดยไม่มีข้อผิดพลาดเกี่ยวกับการตรวจสอบไฟล์ที่ไม่ถูกต้องหรือไม่
3. ทำซ้ำขั้นตอนนี้กับเส้นทางพร็อกซีหรือสำเนาแต่ละรายการ จากนั้นตรวจสอบว่าคู่คีย์ยังคงถูกติดตั้งอยู่หลังจากรีสตาร์ทคอนเทนเนอร์หรือเปลี่ยนพอด

การเปิดเอกสารสำเร็จจะตรวจสอบเฉพาะเส้นทางนั้นเท่านั้น ทำซ้ำการตรวจสอบสำหรับโฮสต์ WOPI และเส้นทางพร็อกซีแต่ละรายการที่คุณใช้งาน

ข้อมูลอ้างอิงอย่างเป็นทางการ

• คู่มือการใช้งาน Collabora Online SDK เวอร์ชัน 24.04: การตั้งค่าคู่คีย์พิสูจน์ WOPI
• การตั้งค่า proof-key อย่างเป็นทางการของ Helm chart จาก Collabora
• ส่วนหัวและรูปแบบการตรวจสอบความถูกต้องแบบกำหนดเองของ Microsoft MS-WOPI
• คำแนะนำการตรวจสอบความถูกต้องของรหัสพิสูจน์อักษรของ Microsoft