اكتشف مطور برمجيات خللًا سمح باستخدام توقيع موافقة بشري مُعدّ للاستخدام مرة واحدة، مرتين في نفس اللحظة. هذا يسلط الضوء على أهمية التصميم الدقيق للأنظمة لمنع الأخطاء غير المقصودة في العمليات الهامة.
هل تساءلت يومًا ما إذا كان توقيع رقمي «لمرة واحدة» يمكن استخدامه فعليًا أكثر من مرة؟ حسنًا، اكتشف مطور برمجيات هذا الاحتمال بالذات أثناء بناء مشروع لمسابقة هاكاثون Google Cloud. كان نظام موافقته البشرية مصممًا للتحقق من التوقيع، ثم تنفيذ الإجراء، ثم وضع علامة على التوقيع بأنه مستخدم. لكن ما لم يتوقعه هو أن نقرتين متزامنتين تمامًا من مشغلين مختلفين كانتا كافيتين لتشغيل الإجراء مرتين!
المشكلة تكمن في الترتيب. كان النظام يقوم أولًا بالتحقق من التوقيع، ثم تشغيل العملية المطلوبة، وبعد ذلك فقط يقوم بوضع علامة على التوقيع بأنه قد استُخدم. في بيئات عمل الخوادم التي تعالج طلبات متعددة في وقت واحد، يمكن لطلبين يصلان في نفس اللحظة أن يحصلا كلاهما على موافقة «نعم»، مما يسمح بتشغيل الإجراء مرتين بنفس التوقيع الذي كان من المفترض أن يُستخدم مرة واحدة فقط. وكانت السجلات تظهر عملية واحدة فقط، وهو ما يجعل اكتشاف المشكلة أصعب.
لحسن الحظ، لم يكن الحل معقدًا أبدًا، بل كان يتعلق بالترتيب الصحيح للخطوات. الفكرة ببساطة هي: يجب أولاً البحث عن التوقيع واستهلاكه (بمعنى تسجيل استخدامه) تحت قفل يمنع أي عمليات أخرى من الوصول إليه في نفس الوقت، ومن ثم تنفيذ الإجراء المطلوب. وإذا حدث أي خطأ قبل تنفيذ الإجراء، يتم «إرجاع» التوقيع لضمان عدم فقده بسبب مشكلة عابرة. هذا الترتيب البسيط والمنطقي هو الذي حل المشكلة، وأصبح الآن هناك اختبارات تضمن عدم تكرارها.
لم تكن هذه المشكلة الوحيدة التي واجهها. فقد اكتشف أيضًا خللًا مشابهًا في طريقة تسجيل الأحداث في سجل التدقيق الخاص به. تحديث رأس السلسلة كان يتم بقراءة البيانات، ثم تعديلها، ثم إعادة كتابتها بدون أي قفل. هذا يعني أن حدثين يمكن أن يتداخلا، ويدعيا نفس الموضع، مما يؤدي إلى «تشعب» السلسلة دون أن يلاحظ أحد ذلك فورًا، ولن يظهر الخلل إلا بعد فترة طويلة.
هذا يكشف لنا درسًا قيمًا: حتى الأنظمة المعقدة والذكية تحتاج إلى اهتمام بالغ بالتفاصيل والاختبارات الشاملة. الأخطاء البسيطة في ترتيب العمليات يمكن أن تكون لها عواقب كبيرة، خاصة عندما يتعلق الأمر بالموافقات الرقمية والإجراءات التي لا رجعة فيها. إن بناء أنظمة موثوقة لا يقتصر على الميزات المبتكرة، بل على أساسيات المتانة والوقاية من المشاكل الخفية مثل «ظروف السباق». هذا يضمن أن موافقاتك الرقمية تعني حقًا الاستخدام لمرة واحدة فقط.
المشكلة تكمن في الترتيب. كان النظام يقوم أولًا بالتحقق من التوقيع، ثم تشغيل العملية المطلوبة، وبعد ذلك فقط يقوم بوضع علامة على التوقيع بأنه قد استُخدم. في بيئات عمل الخوادم التي تعالج طلبات متعددة في وقت واحد، يمكن لطلبين يصلان في نفس اللحظة أن يحصلا كلاهما على موافقة «نعم»، مما يسمح بتشغيل الإجراء مرتين بنفس التوقيع الذي كان من المفترض أن يُستخدم مرة واحدة فقط. وكانت السجلات تظهر عملية واحدة فقط، وهو ما يجعل اكتشاف المشكلة أصعب.
لحسن الحظ، لم يكن الحل معقدًا أبدًا، بل كان يتعلق بالترتيب الصحيح للخطوات. الفكرة ببساطة هي: يجب أولاً البحث عن التوقيع واستهلاكه (بمعنى تسجيل استخدامه) تحت قفل يمنع أي عمليات أخرى من الوصول إليه في نفس الوقت، ومن ثم تنفيذ الإجراء المطلوب. وإذا حدث أي خطأ قبل تنفيذ الإجراء، يتم «إرجاع» التوقيع لضمان عدم فقده بسبب مشكلة عابرة. هذا الترتيب البسيط والمنطقي هو الذي حل المشكلة، وأصبح الآن هناك اختبارات تضمن عدم تكرارها.
لم تكن هذه المشكلة الوحيدة التي واجهها. فقد اكتشف أيضًا خللًا مشابهًا في طريقة تسجيل الأحداث في سجل التدقيق الخاص به. تحديث رأس السلسلة كان يتم بقراءة البيانات، ثم تعديلها، ثم إعادة كتابتها بدون أي قفل. هذا يعني أن حدثين يمكن أن يتداخلا، ويدعيا نفس الموضع، مما يؤدي إلى «تشعب» السلسلة دون أن يلاحظ أحد ذلك فورًا، ولن يظهر الخلل إلا بعد فترة طويلة.
هذا يكشف لنا درسًا قيمًا: حتى الأنظمة المعقدة والذكية تحتاج إلى اهتمام بالغ بالتفاصيل والاختبارات الشاملة. الأخطاء البسيطة في ترتيب العمليات يمكن أن تكون لها عواقب كبيرة، خاصة عندما يتعلق الأمر بالموافقات الرقمية والإجراءات التي لا رجعة فيها. إن بناء أنظمة موثوقة لا يقتصر على الميزات المبتكرة، بل على أساسيات المتانة والوقاية من المشاكل الخفية مثل «ظروف السباق». هذا يضمن أن موافقاتك الرقمية تعني حقًا الاستخدام لمرة واحدة فقط.
