كيفية إصلاح خطأ "فشل التحقق من صحة إثبات WOPI" في Collabora Online

ابدأ بالنظام الذي سجل الفشل

تعني عبارة "فشل التحقق من صحة إثبات WOPI" أن مضيف WOPI لم يتمكن من التحقق من طلب موقّع من Collabora Online. في إعداد Nextcloud Office النموذجي، يُعد Nextcloud مضيف WOPI، بينما يُعد Collabora عميل WOPI: يرسل Collabora الطلب الموقّع، ويتحقق منه المضيف. تختلف الصياغة الدقيقة باختلاف التكامل والإصدار، لذا حدد أولًا المكوّن الذي أصدر الرسالة والطلب الذي فشل.

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

الخطوة الأولى: كرر الخطأ مرة واحدة، وسجّل الوقت، ونوع الملف، وحالة HTTP، ومعرّف الطلب أو الارتباط، ثم افحص سجلات منصة التخزين وسجلات Collabora coolwsdبحثًا عن نفس الحدث. لا تُرسل رموز الوصول، أو رؤوس الإثبات، أو المفاتيح الخاصة في التذكرة.

طاولة التشخيص السريع

1. تأكيد الاكتشاف يكشف المفتاح العام الحالي

تنشر Collabora إمكانيات WOPI ومعلومات مفتاح الإثبات عند نقطة اكتشاف البيانات. من جهاز يمكنه الوصول إلى عنوان URL الخاص بـ Collabora المستخدم من قِبل خادم التخزين الخاص بك، افحص ما يلي:

curl -fsS https://office.example.com/hosting/discovery

ابحث في ملف XML عن proof-keyعنصر يحتوي على قيمة حالية value، وقيمة أخرى إن وجدت oldvalue. لا تخلط بين هذه البيانات العامة والمفتاح الخاص المخزن على خادم Collabora. أفضل مقارنة هي استجابة الاكتشاف التي يجلبها مضيف WOPI نفسه، لأن المتصفح أو محطة عمل المسؤول قد تتلقى استجابة مختلفة عبر نظام أسماء النطاقات (DNS) أو خادم وكيل أو ذاكرة تخزين مؤقتة.

تم التحقق: يستخدم تكامل WOPI الخاص بـ Collabora توقيعات إثبات، ويتم توفير المفتاح العام من خلال عملية الاكتشاف. الإجراء: جلب بيانات الاكتشاف من المضيف/الحاوية الفعلية التي تتحقق من صحة الطلبات، ثم التأكد من صحة ملف XML ومطابقته لنقطة نهاية Collabora المُكوّنة في منصة التخزين. يوضح دليل ربط Collabora SharePoint آلية إنشاء مفتاح الإثبات واكتشافه.

2. تحقق مما إذا كان المفتاح الخاص موجودًا وقابلًا للقراءة

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

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

sudo coolconfig generate-proof-key

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

3. ابحث عن عدم تطابق المفاتيح عبر العقد أو ذاكرات التخزين المؤقت

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

الإجراء: جلب البيانات /hosting/discoveryعبر موازن الأحمال ومباشرةً من كل خادم خلفي، إن كان ذلك مسموحًا. قارن قيم المفتاح العام وتأكد من أن ذاكرة التخزين المؤقت لاكتشاف مضيف WOPI محدّثة. إذا كانت العُقد تستخدم مفاتيح منفصلة عمدًا، فتحقق من أن تكامل التخزين يدعم هذه البنية؛ وإلا، فاحرص على اتساق تكوين مفتاح الإثبات عبر المجموعة. يجب أن يستخدم تحديث الاكتشاف الآلية المدعومة من التكامل. تجنب تعديل ذاكرة التخزين المؤقت لقاعدة البيانات أو إعادة تشغيل الخدمات غير ذات الصلة دون دليل.

4. قارن عنوان URL المُوقّع مع عنوان URL الذي يتحقق منه المضيف

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

الإجراء: ربط طلب فاشل واحد على مستوى الخادم الوكيل والتطبيق. قارن المخطط، واسم المضيف، والمنفذ الصريح، والمسار، والأحرف المشفرة التي رآها المدقق مع عنوان URL المستخدم في رمز التحقق من صحة الإثبات. تحقق من معالجة forwarded-host و forwarded-proto فقط إذا كان التطبيق يعتمد على هذه العناوين. احتفظ بعنوان URL الحقيقي للطلب؛ لا تقم "بإصلاح" المشكلة عن طريق تعطيل عمليات التحقق من التوقيع أو الوثوق بعناوين إعادة توجيه عشوائية.

5. التحقق من صحة الطابع الزمني ومعالجة البايتات

يتضمن دليل WOPI هذا X-WOPI-TimeStampالعنصر. في مواصفات Microsoft WOPI، يُمثل هذا العنصر عددًا صحيحًا من 64 بت، يُقاس بفواصل زمنية قدرها 100 نانوثانية منذ 1 يناير 0001، وليس طابعًا زمنيًا بنظام يونكس بالثواني. قد يؤدي أي مُدقِّق مُخصَّص يُحلِّله على أنه ثوانٍ بنظام يونكس، أو يُسقط أرقامًا، أو يُغيِّر الترميز، أو يُجمِّع البايتات المُوقَّعة بشكل غير صحيح، إلى رفض الطلبات الصحيحة.

يُعدّ انحراف التوقيت أحد الأسباب المحتملة عندما يفرض المضيف فترة صلاحية، ولكن التسامح الدقيق يعتمد على آلية التحقق. تستخدم إرشادات مايكروسوفت لـ Microsoft 365 للويب فحصًا للعمر كل 20 دقيقة؛ لا تفترض أن هذا الرقم ينطبق على جميع عمليات تكامل Collabora. الإجراء: تحقق من مزامنة NTP وتوقيت UTC على Collabora وأنظمة التخزين، ثم افحص قاعدة الطابع الزمني الموثقة الخاصة بالمضيف ورمز التحليل.

تحقق أيضًا من بنية البيانات على مستوى البايت إذا كنت تستخدم مضيف WOPI مخصصًا. الرمز المميز بتنسيق UTF-8؛ الأطوال هي عدد البايتات؛ عنوان URL هو عنوان URL المطلق الكامل بأحرف كبيرة؛ ويجب تمثيل قيمة الطابع الزمني تمامًا كما هو محدد. يجب أن يتطابق المفتاح العام مع المفتاح الخاص الذي استخدمته منصة Collabora التي أرسلت الطلب.

6. فصل حالات فشل الإثبات عن أخطاء قائمة السماح وأخطاء TLS

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

بالنسبة لعمليات نشر Nextcloud، يوصي دليل استكشاف الأخطاء وإصلاحها الرسمي بالتحقق من مسارات HTTP(S) المطلوبة في كلا الاتجاهين، ومراجعة سجلات Nextcloud وCollabora، والتأكد من إدخالات قائمة السماح لمضيف WOPI بحثًا عن تحذيرات قائمة السماح. الإجراء: اتبع فئة الخطأ في السجل. اختبر نقطة نهاية الاكتشاف وإمكانية الوصول إلى الشبكة بشكل منفصل عن مدقق الإثبات. لا توسّع قائمة السماح *كحل بديل.

تسلسل الاسترداد الآمن

1. قم بتسجيل وقت فشل الطلب بدقة، وحدد الخدمة التي سجلت فشل التحقق من صحة الإثبات.
2. تحقق من سجلات Collabora بحثًا عن تحذيرات المفاتيح المفقودة؛ وافحص ملف XML الخاص بالاكتشاف من مسار الشبكة الخاص بمضيف WOPI.
3. قارن المفتاح العام في عملية الاكتشاف مع المفتاح الخاص وتكوين العقدة المستخدمة لتوقيع الطلب.
4. تحقق من اتساق موازن الأحمال، وتخزين الاكتشاف المؤقت، وأي تغييرات حديثة في المفاتيح أو اسم المضيف أو الوكيل أو بروتوكول TLS.
5. قارن عنوان URL للطلب الموقع ومعالجة الطابع الزمني دون الكشف عن الرموز المميزة أو رؤوس الإثبات.
6. أعد الاختبار باستخدام مستند واحد وتأكد من نجاح الطلب نفسه في سجلات المضيف قبل استعادة حركة المرور العادية.

إذا استمر الفشل، فاجمع سجلات مُنقّحة من كلا الطرفين، وإصدارات Collabora والتخزين، ونوع النشر، وما إذا كانت عقدة واحدة أو عدة عقد مُشاركة، وملف XML للاكتشاف بعد إزالة البيانات السرية، ومسار الوكيل للطلب الفاشل. شارك هذه المعلومات مع المورّد المعني أو القائمين على صيانة التكامل. لا يُحدد نص الخطأ وحده ما إذا كان السبب هو اكتشاف قديم، أو توحيد عنوان URL، أو مشكلة في الساعة، أو خطأ في أداة التحقق المُخصصة؛ بل تُحدد الأدلة على مستوى الطلب المسار الذي يجب اتباعه.