يفتح موظفان بطاقة عميل افتراضية. يحفظ الأول تغيير الهاتف، ثم يحفظ الثاني ملاحظة من شاشة فُتحت سابقًا. إذا أرسل الثاني نسخة البطاقة كلها دون شرط، قد يمحو تعديل الهاتف وهو لا يراه. قيمة الإصدار تجعل التعارض مرئيًا قبل الكتابة.
اربط الحفظ بالنسخة المقروءة
عند قراءة المورد، يعيد الخادم ETag صالحًا لتمثيل النسخة التي ستُعدل. ترسل الواجهة هذه القيمة في If-Match عند طلب الحفظ. المقارنة هنا قوية؛ قيمة ضعيفة تبدأ بـ W/ ليست بديلًا عن وسم إصدار قوي. عند عدم المطابقة، تكون استجابة الشرط الفاشل 412 في السيناريو المعتاد.
المرجع: MDN If-Match.
لا تفصل المقارنة عن الكتابة
إذا قرأ الخادم الإصدار ثم كتب في خطوة مستقلة من دون حماية التزامن، قد ينجح طلبان بعد قراءة الإصدار نفسه. اجعل شرط النسخة جزءًا من عملية تحديث ذرية أو استخدم معاملة تحمي القرار. نفذ التفويض أيضًا؛ امتلاك ETag صحيح لا يمنح حق تعديل السجل.
أعد تعارض النافذتين
اقرأ البطاقة في نافذتين، ثم احفظ من الأولى وتحقق من تغير الوسم. أرسل من الثانية تعديلًا بالوسم السابق وتحقق من 412 وبقاء قيمة الهاتف الجديدة. اترك الملاحظة غير المحفوظة أمام المستخدم، واعرض مسارًا لإعادة القراءة والمراجعة. لا تعِد إرسال الطلب تلقائيًا بوسم أحدث حتى لا تلغي الحماية.
اختبر الطلبات الحدية
راجع سياسة endpoint إذا غاب الشرط؛ تجاهله قد يسمح لمسار قديم بتجاوز الحماية. اختبر كذلك أن الوسم يتغير عند تعديل الحقول الداخلة في النسخة وأن استجابة التعارض لا تكشف بيانات لغير المصرح له. دليل القبول هو حفظ تعديل واحد وفصل التعارض الآخر بوضوح.
لربط الاختبار بتنفيذ مشروعك، راجع أنظمة إدارة علاقات العملاء وتطوير المواقع والمتاجر.
صورة توضيحية أصلية لشرح الفكرة، وليست لقطة نظام عميل أو نتيجة قياس فعلية.
