Summary

  • تضيف مراجعة 27 أكتوبر لمسودة إنترنت فردية decision.operationKey لتمييز العملية المقصودة: المحاولة المتكررة تحتفظ بالمفتاح، والدفع الجديد يأخذ مفتاحاً جديداً.
  • في مثال المسودة، من أصل حد قدره 500 جنيه صُرف 300 وحُجز 120. إعادة العملية لا ترفع الالتزام عن 420؛ أما دفعة جديدة بقيمة 120 فترفعه إلى 540.

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

تعالج المراجعة الجديدة للمسودة هذا الالتباس بمفتاح للعملية المقصودة. يضع الوكيل decision.operationKey في الطلب الموقّع. كل محاولة لتنفيذ القرار نفسه تحمل المفتاح ذاته؛ أما قرار دفع مستقل فيحمل مفتاحاً آخر، ولو تطابقت تفاصيله. ويُقرأ المفتاح ضمن نطاق خلاصة الوثيقة التي تحدد سقف التفويض، limitDigest، حتى يبقى واضحاً أي سلطة مالية استُخدمت.

في المراجعة السابقة -01 كان التعرف على الإعادة يعتمد على خلاصة الطلب. هذه الخلاصة تصف الفعل ووسيطاته والمورد المقصود. يمكن لتكليفين مستقلين أن يتشاركاها. يسجل تاريخ الوثيقة الآن أن الدفعة الثانية قد تبدو، خطأً، مجرد تكرار للأولى فلا تدخل الحساب.

الأرقام في مثال المؤلف تكشف الثغرة بسرعة. الحد 50 ألف بنس، والمصروف فعلاً 30 ألفاً، وهناك تصريح بـ12 ألفاً معلّق لأن الرد ضاع. حين يعود الطلب بمفتاح العملية نفسها، يبقى مجموع المصروف والمحجوز 42 ألفاً. أما إذا وصل طلب جديد بقيمة 12 ألفاً ومفتاح جديد، يصبح الإجمالي 54 ألفاً ويتجاوز الحد. لا يصح أن يصبح المبلغ الزائد غير مرئي لأن رسالتي الدفع تشبهان بعضهما.

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

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

يعرض سجل IETF النص بوصفه Internet-Draft فردياً في حالة I-D Exists. السؤال الذي يطرحه يخص كل تفويض آلي بالإنفاق: هل نعرف أي وعد مالي تكرر إرساله، وأي وعد جديد أُضيف؟