فحص تنسيق مفتاح عدم التكرار

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

لماذا تحتاج مفاتيح عدم التكرار إلى فحص تنسيق

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

ما الذي يتم التحقق منه بالضبط

يطبّق الفحص إرشادات التنسيق التي توثّقها معالجات الدفع وبرمجيات إزالة التكرار الوسيطة في أغلب الأحيان. أولًا، يجب أن يكون المفتاح سلسلة نصية غير فارغة؛ فالمفتاح الفارغ خطأ وليس تحذيرًا، لأن أي خادم لن يقبله. ثانيًا، الطول: يجب افتراضيًا ألّا يقل المفتاح عن 16 حرفًا، وهو الحد الأدنى الذي تتوقف تحته فرادة المفتاح عن أن تكون معقولة، وألّا يزيد عن 255 حرفًا، وهو السقف الذي تقبله معظم المخازن — وكلا الحدّين قابلان للضبط في كل استدعاء. ثالثًا، الأبجدية: يجب أن ينتمي كل حرف إلى المجموعة غير المحجوزة في RFC 3986 — الحروف والأرقام والشرطة والنقطة والشرطة السفلية والتلدة. هذه الأحرف تعبر ترويسات HTTP ومقاطع URL وناقلات السجلات دون ترميز، وهذا بالضبط هو المسار الذي تسلكه مفاتيح عدم التكرار. وعندما يفشل حرف ما، تعدّد الاستجابة كل حرف مخالف متميز لترى ما إذا كان أحدهم قد أدرج مسافة أو شرطة مائلة أو رمزًا تعبيريًا، وتسمّي مصفوفة issues المشكلة بصيغة مقروءة آليًا: too_short أو too_long أو unsafe_characters.

أين يندرج الفحص في بنيتك التقنية

تدمجه معظم الفرق في موضعين. الأول هو العميل الذي يولّد المفاتيح: فور بنائك مفتاحًا من UUID وطابع زمني ومعرّف مستخدم، تحقّق منه مرة واحدة وسجّل تحذيرًا إن فشل، كي يظهر خطأ المولّد في بيئة الإعداد لا في الإنتاج. الثاني هو اختبار العقود: أرسل دفعة من المفاتيح من كل تكامل تملكه إلى نقطة النهاية في التكامل المستمر، بحيث يُفشِل البناءَ أيُّ تحديث لمكتبة يغيّر سلوك الترميز. نقطة النهاية حتمية وعديمة الحالة — لا يُخزَّن شيء، ولا تُراجَع أي قائمة بالمفاتيح السابقة، والمدخل نفسه ينتج دائمًا المخرج نفسه — أي إن استدعاءها بمفاتيح حقيقية آمن، وبتكلفة $0.002 لكل طلب فهي رخيصة بما يكفي لتشغيلها مع كل نشر. ويعمل التحقق نفسه مجانًا في متصفحك على هذه الصفحة، فيمكن للمطوّر لصق مفتاح مشبوه أثناء حادثة والحصول على الإجابة نفسها التي ستقدّمها واجهة برمجة التطبيقات.