إصلاح أخطاء إثبات WOPI عن طريق فحص المفاتيح والاكتشاف وعناوين URL

عندما يُبلغ مُضيف WOPI عن "فشل التحقق من صحة الإثبات" أو "إثبات WOPI غير صالح"، تأكد أولاً من النظام الذي سجل الرفض. إذا كان مُضيف التخزين يرفض طلب Collabora المُوقّع، فتحقق من زوج مفتاح الإثبات واستجابة الاكتشاف قبل تغيير قوائم السماح لمُضيف WOPI أو تعطيل عمليات التحقق من الإثبات. بالنسبة لتثبيتات الحزم، يُنشئ Collabora عادةً زوج المفاتيح؛ أما بالنسبة لـ Docker وKubernetes وعمليات النشر متعددة النسخ، فيجب توفير الزوج وحفظه باستمرار.

حدد الفحص الفاشل قبل تغيير المفاتيح

تعتمد عملية التحقق من صحة إثبات WOPI على طلب مُوقّع والمفتاح العام الذي يُعلنه عميل WOPI في بيانات التعريف الخاصة به. وهي عملية منفصلة عن قائمة مضيفي WOPI الموثوق بهم في Collabora، والتحقق من صحة شهادة TLS، وفحص رمز الوصول الخاص بمضيف التخزين. قد يُفيد إعادة إنشاء المفتاح في حال فقدان المفتاح الخاص أو عدم تطابقه مع المفتاح العام المُعلن عنه، ولكن قد يُؤدي ذلك إلى عدم تطابق جديد إذا تغيّرت نسخة واحدة فقط أو إذا كان لدى المضيف بيانات اكتشاف مُخزّنة مؤقتًا.

تحقق من طلب واحد فاشل في كل من سجلات Collabora و storage-host؛ لا يشير مؤشر التحميل في المتصفح وحده إلى فشل مفتاح الإثبات.

اختر الإصلاح المناسب لعملية النشر

ابدأ بالخيار الأقل إزعاجًا. في حالة التثبيت باستخدام الحزم، تحقق أولًا من ملفات المفاتيح وسجلات الخدمة الموجودة؛ تشير وثائق Collabora الحالية إلى أن تثبيت حزم RPM وDebian يُنشئ زوجًا من مفاتيح إثبات WOPI تلقائيًا. إذا كانت هذه الملفات موجودة ومستقرة، فعادةً لا يكون تدويرها ضروريًا.

يذكر دليل Collabora 24.04 أن صورة Docker العامة لا تتضمن زوجًا من مفاتيح الإثبات؛ لذا قم بإنشاء واحد وتثبيته بشكل دائم. يدعم مخطط Helm الرسمي مفاتيح الإثبات السرية. تجنب إنشاء زوج منفصل لكل نسخة، وإلا فقد يؤدي ذلك إلى حدوث أعطال متقطعة في موازنة الأحمال.

افحص وأصلح زوج المفاتيح بأمان

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 ومسار الوكيل الذي تقوم بتشغيله.

المراجع الرسمية

• دليل استخدام حزمة تطوير البرامج (SDK) لكولابورا أونلاين 24.04: إعداد زوج مفاتيح إثبات WOPI
• إعدادات مفتاح إثبات مخطط Helm الرسمي لـ Collabora
• رؤوس مخصصة وتنسيق إثبات Microsoft MS-WOPI
• إرشادات مايكروسوفت للتحقق من صحة مفتاح الإثبات