الخلاصة

  • يخبر Open Cloud Mesh الطرف المتلقي بأنه مُنح الوصول، لكنه يتوقف قبل عملية WebDAV أو SSH أو التطبيق التي تجعل المنحة نتيجة فعلية.
  • تكشف مسودّة تكامل OCM الجديدة حداً مهماً: الإشعار والاعتماد الصالح ونجاح عملية المورد ثلاثة سجلات مختلفة.

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

تشرح draft-ietf-ocm-integration-protocol-00، وهي أول نسخة لمجموعة العمل نُشرت في 11 سبتمبر، هذا الفصل. ينسّق OCM الاتحاد: يبلغ Sending Server نظيره Receiving Server بأن طرفاً مُنح الوصول إلى Resource. يأتي الوصول الفعلي لاحقاً عبر WebDAV أو SSH أو بروتوكول تطبيق. وتسمح المسودّة بتفويض هذا العمل إلى Protocol Server من دون أن يرى النظير المتلقي اختلافاً في البنية الداخلية.

المسألة ليست تقسيم منتج؛ إنها فصل الإعلان عن التفويض، والتنفيذ عن النتيجة.

الإشعار يفتح الطريق ولا يثبت نهايته

تحمل Share Creation Notification الأطراف وproviderId ومداخل البروتوكول والصلاحيات ووقت الانتهاء. يمكنها تحديد مكان الطلب التالي، لكنها لا تحمل جواب ذلك الطلب.

يربط providerId حالة Share في القناة الخلفية بالاعتماد في القناة الأمامية. ومع ذلك تسميه المسودّة معرّفاً لا credential؛ لا يجوز أن يمنح مجرد امتلاكه أي وصول. يأتي التفويض من access token متحقق منه أو، في نمط introspected، من اعتماد يؤكد endpoint أنه active.

حتى JWT صالح لا يثبت إلا دعوى محدودة. التوقيع يحدد المُصدر ويحمي claims. وعلى Protocol Server أيضاً التحقق من issuer وaudience وsubject والانتهاء وpairing وحالة Share، ثم فرض الصلاحيات. بعد ذلك يجب على التخزين أو التطبيق تنفيذ العملية. التوقيع الصحيح لا ينشئ ملفاً غائباً، ولا يختار النسخة الصحيحة وحده، ولا يحول خطأ WebDAV إلى نقل مكتمل.

نجاح زائف تمنعه المسودّة

في نمط provisioned يرسل OCM Server أولاً Share Provisioning Request موقعة. يتحقق Protocol Server منها، ويحفظ Share Record، ثم يقر بالنجاح. بعد ذلك فقط يجوز إرسال Share Creation Notification.

إذا فشل provisioning فلا يجوز إنشاء Share، وإلا أُبلغ الطرف المتلقي بوصول لا يمكن أن يعمل. تمنع القاعدة حالة محددة: إعلان مشاركة رغم رفض خادم الوصول تجهيزها.

لكنها لا تثبت كل وصول لاحق. قد يفشل تبادل الرمز، أو تنتهي صلاحيته، أو لا تتطابق الهوية، أو ينتقل Resource، أو يتعطل Protocol Server، أو يعيد البروتوكول الأساسي خطأه الخاص. الإيصال الدقيق هو «نجح provisioning قبل الإشعار»، لا «وصل المتلقي إلى المورد».

ثلاثة أنماط وثلاث ساعات

تنتج أنماط provisioned وself-contained وintrospected دعوة متشابهة، لكن إثباتها وساعات الإلغاء مختلفة.

يحفظ provisioned سجلاً للمشاركة ويدعم طلب إلغاء صريحاً. ويضع self-contained معلومات Share في claim موقع باسم ocm_ip؛ لذلك يبقى الرمز الصادر فعالاً حتى انتهاء صلاحيته. أما introspected فيسأل هل الاعتماد active، لكن التخزين المؤقت لجواب إيجابي يؤخر أثر الإلغاء.

لا تكفي عبارة «ألغيت المشاركة عند 14:00» لتحديد نهاية الوصول. يجب، بحسب النمط، إثبات إلغاء السجل أو انتهاء آخر رمز أو انتهاء cache الخاص بالاستعلام. لا حاجة لكشف طوبولوجيا التفويض للنظراء، لكن على المشغل حفظ النمط وخطوة دورة الحياة التي اكتملت فعلاً في سجل محلي محمي.

البروتوكول الأساسي يملك الجواب الأخير

تحافظ أخطاء القناة الأمامية على دلالة WebDAV أو SSH أو التطبيق. لا يدعي OCM نتيجة لم يرها.

في WebDAV قد يشمل الإيصال method وHTTP status وETag أو نسخة المحتوى واكتمال body. وفي SSH لا يثبت التوثيق وفتح الجلسة نجاح الأمر أو نقل الملف المقصود. وفي تطبيق ويب لا يعني فتح صفحة مسموحة اكتمال مهمة الحساب وراءها.

تربط السلسلة القابلة للدفاع خمس طبقات: إشعار Share؛ إصدار الاعتماد أو introspection؛ قرار Protocol Server؛ جواب البروتوكول ونسخة Resource؛ النتيجة لدى تطبيق المتلقي. يمكن للوحة أن تلخص، لكن لا يجوز أن تمحو مصدر كل حقيقة.

المصادر