الخلاصة

  • ينشئ الخادم رمزاً فريداً لكل قفل WebDAV. ظهور الرمز في حقل If يثبت تقديم المعرّف، ولا يثبت هوية المرسل أو صلاحية الكتابة أو بقاء القفل.
  • تمر الكتابة الصحيحة بقرارات منفصلة: توثيق الفاعل، تخويل العملية، تحديد كل الموارد المتأثرة، تقييم الشروط وETag، فحص الأقفال المباشرة والموروثة، مطابقة منشئ القفل أو الاستثناء المخوّل، ثم إعادة فحص الحالة عند التنفيذ.
  • تمنع الأقفال المشتركة وعمق المجموعات وعمليات COPY/MOVE والمهلة التي يختارها الخادم من اعتبار الرمز إيجاراً قابلاً للنقل. إنه دليل تنسيق محدود.

المورد نفسه تحت خريطة سلطة مختلفة

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

إذا قدّم العميل الرمز القديم بعد النقل، فلا تكفي صحة السلسلة لتقرير الكتابة. يفرض RFC 4918 على الخادم، عند تعديل مورد مقفول، أن يتحقق من تطابق الفاعل الموثق مع منشئ القفل إضافة إلى التحقق من تقديم الرمز الصحيح. كما أن امتلاك القفل لا يمنح كامل امتيازات التعديل؛ تبقى آليات التوثيق والتخويل العادية نافذة.

قد يكون الرمز قد وُلد بطريقة صحيحة، لكن الحساب تبدّل، أو أُلغيت صلاحية الكتابة، أو تغير نطاق القفل، أو صار ETag قديماً، أو أصبحت الوجهة تحتاج امتياز ربط مختلفاً. الرمز يجيب عن سؤال واحد: أي قفل يعرفه الطلب؟ أما من يتكلم، وماذا يستطيع، وأي موارد ستتغير، وهل الحالة الحالية تقبل العملية، فهي أسئلة لطبقات أخرى.

فرادة قوية لادعاء ضيق

يوسع WebDAV بروتوكول HTTP من أجل التأليف البعيد والخصائص والمجموعات وعمليات فضاء الأسماء وتفادي التصادم. الغاية الأساسية من قفل الكتابة تقليل التحديث الضائع عندما يستبدل محرر عمل محرر آخر من غير علم.

لكل قفل رمز واحد فريد ينشئه الخادم. لا يجوز للعميل تفسير بنية الرمز. يشترط RFC 4918 أن تكون URI الخاصة بالرمز فريدة عبر الموارد والزمن. وعند إنشاء قفل جديد بنجاح، يعيد الخادم القيمة في حقل الاستجابة Lock-Token وفي جسم الاستجابة.

هذه الفرادة تمنع الخلط بين سجلين؛ لا تفوض حقاً. ويمكن أن تعرض خاصية DAV:lockdiscovery معلومات الأقفال النشطة، ولهذا لا يجوز أن تعتمد الحماية على غموض الرمز وحده.

يشجع RFC 4918 استخدام URN من نوع UUID، ويبقي مخطط opaquelocktoken مسجلاً بصورة دائمة، ويسمح بأي URI فريدة. يوصي RFC 9562 بمولد عشوائي زائف آمن تشفيرياً حين تكون صعوبة التخمين مطلوبة. العشوائية تقلل التنبؤ، لكنها لا تقرأ سياسة DAV:write-content أو DAV:bind.

يجب فصل ست وظائف: الفرادة تميز الأقفال؛ صعوبة التخمين تحد من الاكتشاف؛ التقديم يثبت معرفة القيمة؛ التوثيق يربط الطلب بفاعل؛ التخويل يحدد الفعل المسموح؛ والتنفيذ يجعل التغيير حقيقة في الحالة الحالية. لا ينبغي للرمز أن يستولي على الوظائف الثلاث الأخيرة.

منشئ القفل ليس مالك المورد

لمنشئ القفل علاقة خاصة به، لكن داخل الصلاحيات العادية. ويمكن للخادم أن يسمح لمالك مورد أو مدير أو فاعل ذي امتياز بإزالة قفل تركه صاحبه.

يفصل RFC 3744 معنى الكتابة. يتحكم DAV:write-content في تعديل المحتوى القائم، وDAV:write-properties في الخصائص، وDAV:bind في إضافة عضو إلى مجموعة، وDAV:unlock في تنفيذ UNLOCK من فاعل غير مالك القفل. إنشاء مورد عبر PUT على URI غير معيّنة يتعلق بامتياز الربط في المجموعة الأم.

إذن لا تسمح صلاحية الكتابة بتجاهل قفل شخص آخر، ولا يسمح الرمز بتجاوز قائمة التحكم. ويجب أن يظهر فك القفل الإداري كاستثناء مخوّل ومنسوب، لا كحيازة مصطنعة.

ينسجم ذلك مع تمييز Heng Lu بين السجل والسلطة. يسجل الرمز علاقة تنسيق مفيدة، لكنه لا يصبح مصدر السيادة. السلطة العملية تبقى لدى الأنظمة التي توثق الهوية وتقيّم السياسة وتحل فضاء الأسماء وتكتب التخزين وتنفذ التعافي.

وظيفتان داخل If

يحمل حقل WebDAV المسمى If شروطاً، ويقدم رموز الحالة في الوقت نفسه.

داخل قائمة واحدة تُجمع الشروط بمنطق AND، وتعمل القوائم البديلة بمنطق OR، وتنفي Not الشرط التالي. تنطبق القوائم غير الموسومة على Request-URI، بينما تسمي القوائم الموسومة المورد المقصود.

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

إذا اختزل وسيط الحقل إلى «الفرع الفائز»، فقد يحذف رمزاً مطلوباً لمورد آخر. وإذا سجل فقط «الرمز موجود»، فقد يخفي فشل شرط ETag. ينبغي حفظ القيم المقدمة والقوائم التي قُيّمت والموارد التي تخصها والنتيجة كل على حدة.

لذلك يختلف 412 عن 423. شرط If الكاذب يؤدي إلى 412 Precondition Failed بعد فحص التخويل. غياب رمز مطلوب لمورد مقفول ستؤثر فيه العملية يؤدي إلى 423 Locked مع الشرط lock-token-submitted. الأول فشل في ادعاء الحالة، والثاني نقص في دليل القفل.

أما Lock-Token فله نطاق أضيق: يعيد الرمز الجديد في استجابة LOCK، ويحدد القفل المطلوب حذفه في طلب UNLOCK. تقدم PUT وPROPPATCH وCOPY وMOVE وDELETE الرموز عبر If.

العنوان الظاهر ليس مجموعة التأثير كاملة

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

قد يكون الملف مقفلاً بسبب المجموعة الأم حتى لو لم تعرض واجهة العميل ذلك. على الخادم أن يحل خريطة الأسماء الحالية ويجمع كل الأقفال المنطبقة.

يسمح LOCK بعمق صفر أو infinity، ويكون infinity هو الافتراضي. إذا منع عضو غير متوافق قفل شجرة، فلا يجوز ترك قفل جزئي. تنجح العملية ضمن النطاق كله أو تفشل، ويمكن أن يحدد Multi-Status المورد المانع.

توسع COPY وMOVE وDELETE المجموعة المتأثرة. قد تتغير المصدر والوجهة والمجموعة الأم ومورد تتم الكتابة فوقه. يجب تقديم رموز كل الموارد التي يلزم فكها لإتمام العملية.

وتكشف MOVE خطأ «الإيجار المحمول»: القفل المباشر لا يتبع المورد إلى URL الجديدة. تتغير الأقفال الموروثة بحسب المصدر والوجهة. المعنى تابع لفضاء الأسماء الراهن، لا لجوهر دائم داخل المحتوى.

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

القفل المشترك ليس كلمة مرور جماعية

يسمح القفل المشترك بأقفال مشتركة متوافقة، لكن كل طلب LOCK ناجح ينشئ قفلاً ورمزاً مستقلين. ثلاثة متعاونين يملكون ثلاث علاقات تنسيق، لا رمزاً يمثل جماعة واحدة.

تجديد قفل لا يجدد الآخرين. وإزالة قفل عبر UNLOCK لا تضمن أن المورد صار حراً؛ قد يبقى قفل مشترك آخر أو قفل موروث.

يقرر التطبيق طريقة الدمج والمراجعة وحل الخلاف والنسخة النهائية. كلمة «مشترك» تصف التوافق التقني، ولا تنشئ تصويتاً أو ملكية جمعية.

يجب أن تعرض الواجهة المنشئ والجذر والعمق والعلاقة المباشرة أو غير المباشرة والمهلة، وما الذي أزاله كل UNLOCK. المؤشر الثنائي «مقفول/مفتوح» يطمس المعلومات الحاسمة.

المهلة اقتراح يحسمه الخادم

يمكن للعميل أن يقترح مدة في Timeout، لكن الخادم يختار القيمة الفعلية وقد يتجاهل الطلب أو يغيره.

يستخدم التجديد LOCK بلا جسم ورمزاً واحداً في If. يتجاهل الخادم Depth، ويعيد تشغيل العداد إذا نجح، ولا يغير الأقفال المشتركة الأخرى، ويعيد DAV:lockdiscovery محدثاً. ولا يعيد Lock-Token جديداً.

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

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

مسار كتابة قابل لإعادة البناء

يفصل المسار السليم المراحل الآتية:

  1. توثيق الفاعل؛
  2. تخويل العملية المحددة؛
  3. حل المصدر والوجهة والآباء وأهداف الاستبدال؛
  4. اكتشاف الأقفال المباشرة وغير المباشرة والحصرية والمشتركة؛
  5. تحليل If وETag وNot والقوائم البديلة كاملة؛
  6. التأكد من تقديم كل الرموز المطلوبة؛
  7. ربط الفاعل بالمنشئ أو باستثناء مخوّل؛
  8. إعادة فحص الحالة عند التنفيذ وتطبيق الذرية المحددة؛
  9. تسجيل هل فشلت الهوية أو الصلاحية أو الشرط أو الرمز أو النطاق أو الالتزام.

يمكن للسجل حفظ بصمة بمفتاح بدلاً من الرمز الخام. ويجب أن يربطها بالفاعل والطريقة والموارد وجذور الأقفال وأعماقها والقرار والمهلة الفعلية والنسخة النهائية ورمز الاستجابة.

تشمل الاختبارات: رمز صحيح من فاعل مختلف؛ صلاحية بلا رمز؛ رمز مع ETag خاطئ؛ عضو جديد يرث قفل مجموعة؛ فشل قفل شجرة بلا أثر جزئي؛ MOVE لا ينقل القفل المباشر ويطبق قفل الوجهة؛ عدة أقفال مشتركة يُجدد أو يحذف واحد منها فقط؛ فك إداري منسوب؛ ومسار كتابة بديل لا يتجاوز التنسيق بصمت.

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

المصادر