العربية

أدوات المطور · مولد UUID

ما الذي يجعل UUID سلسلة جيدة التكوين، وما لا يستطيع المدقق معرفته

· كيف يعمل

uuid التشفير متصفح API

يتم عرض تمثيلات UUID المتعددة جنبًا إلى جنب: 8-4-4-4-12 الأساسي، بأحرف كبيرة، مع أقواس، بدون واصلة، ومع جرة: بادئة
الرسم التوضيحي المتجه الأصلي ToolAcre

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

400 الذي كان ينبغي أن يكون 404 - إلى أي مدى يؤدي التحقق من صحة UUID إلى حدوث أخطاء API مربكة

تتلقى نقطة النهاية API معرفًا من العميل: {12345678-90AB-CDEF-1234-567890ABCDEF}. يتحقق رمز التحقق من مطابقته /[0-9a-f]{32}/ ويرفضه باعتباره غير صالح. يحصل العميل على 400 طلب غير صالح حيث كان المقصود 404 لم يتم العثور عليه. المعرف منسق بشكل جيد — وهو UUID صالح بتنسيق بين قوسين — ولكن أداة التحقق صارمة للغاية. على العكس من ذلك، فإن نقطة النهاية التي تقبل أي سلسلة سداسية عشرية مكونة من 32 (بدون شرطات) ستقبل 123456789012345678901234567890123456، وتحللها على أنها صالحة، وتفتقد الخطأ المطبعي. RFC 9562 يحدد التمثيل النصي الأساسي، لكن المدخلات الواقعية تصل بخمسة تنسيقات مختلفة، والمدقق الذي يقبل النموذج المتعارف عليه فقط سيرفض 1 إلى 5 بالمائة من المدخلات حسنة النية.

النموذج النصي الأساسي — 32 أرقام سداسية صغيرة في 8-4-4-4-12، بالضبط 36 حرفًا، كما يحدد المعيار للإخراج

النموذج النصي الأساسي هو 32 أرقام سداسية عشرية صغيرة في خمس مجموعات مفصولة بواصلات: 8-4-4-4-12. ممثلة كـ 550e8400-e29b-41d4-a716-446655440000. يفرض المعيار أحرفًا صغيرة على المخرجات؛ عند الإدخال، يوصى بالمطابقة غير الحساسة لحالة الأحرف. هذا النموذج لا لبس فيه، ويوزع إلى وحدات البايت بنفس الطريقة على كل نظام أساسي، وهو ما تقوم كل مكتبة UUID بإخراجه افتراضيًا. إذا كنت تقوم بإنشاء UUID جديد من CSPRNG، فإن النموذج الأساسي هو ما يجب أن تنتجه وما ينتجه ToolAcre. تنحرف مدخلات العالم الحقيقي بطرق يمكن التنبؤ بها. المعرفات ذات الأحرف الكبيرة (550E8400-E29B-41D4-A716-446655440000) شائعة في الأنظمة التي تستخدم الأحرف الكبيرة افتراضيًا؛ فهي تمثل نفس البايتات ويجب قبولها بعد التطبيع إلى أحرف صغيرة.

المتغيرات التي ستقابلها في البرية - الأحرف الكبيرة السداسية، {braces}، urn:uuid: البادئة و32-الأحرف التي لا تحتوي على واصلة، والتي ينص المعيار على قبولها

النموذج المعزز ({550e8400-e29b-41d4-a716-446655440000}) هو الإخراج القياسي من وحدة uuid الخاصة بـ Python وأنظمة Microsoft؛ تجريد الأقواس يعطي شكلًا قانونيًا صالحًا. يتم تعريف البادئة URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000) بواسطة RFC 8141 لأسماء الموارد الموحدة؛ تؤدي إزالة المخطط وبادئة معرف التجريد إلى ترك الشكل الأساسي. النموذج بدون واصلة (550e8400e29b41d4a716446655440000) هو 32 أرقام سداسية بدون بنية؛ إنها وحدات بايت صالحة ولكنها تفقد المجموعة 8-4-4-4-12 التي تجعل الإصدارات والمتغيرات قابلة للقراءة. يتم تعيين جميع هذه المتغيرات إلى نفس قيمة 128 بت. RFC 9562 ينص القسم 3 على أنه عند الإدخال، سيتم قبول المتغيرات الكبيرة SHOULD. ولا يمنع المتغيرات الأخرى. تقول أنه عند الإخراج، سيتم استخدام النموذج الصغير الأساسي MUST.

عقلانية الإصدار والمتغير - ما إذا كان سيتم رفض UUID الذي تبدأ مجموعته الثالثة بـ 0 أو مجموعته الرابعة تبدأ بـ f

يجب على المدقق الجيد: قبول النموذج الأساسي 8-4-4-4-12 بالأحرف الصغيرة أو الكبيرة؛ قبول المتغيرات المدعمة والجرة: عن طريق تجريدها والتحقق من صحة النموذج الأساسي؛ قبول سلاسل سداسية عشرية مكونة من 32 بدون واصلات وتنسيقها على أنها أساسية للمقارنة؛ رفض السلاسل التي تحتوي على عدد خاطئ من الأرقام السداسية أو الأحرف غير السداسية العشرية. الخطأ الأكثر شيوعًا هو رفض الإدخال الكبير أو المثبت لأن أداة التحقق كانت مكتوبة بخط اليد لتتوافق مع النموذج الأساسي فقط. يمكن أن يؤدي التحقق من سلامة الإصدار والمتغير إلى اكتشاف الأخطاء المطبعية. إذا كانت المجموعة الثالثة تبدأ بـ 0 أو 9، ​​فإن UUID غير صالح أو محجوز؛ إذا كانت المجموعة الرابعة تبدأ بـ e أو f، فإن المتغير ليس RFC 9562.

مثال عملي - يتم تشغيل ستة سلاسل مرشحة من خلال فحص صارم وآخر متساهل، مع أسباب النجاح أو الفشل في كل منهما

يقبل المدقق المتساهل هذه القيم؛ يمكن للمدقق الصارم رفضها. يقوم فحص ToolAcre بإجراء التحقق الصارم من الصحة: ​​فهو يؤكد نموذج الأحرف 36 المتعارف عليه مع شرطات في الأماكن الصحيحة، ويتحقق من الأرقام السداسية في كل موضع، ويتحقق من أن الإصدار والبتات المتغيرة موجودة في النطاق. ولا يتحقق من وجود UUID في قاعدة البيانات الخاصة بك أو أنه تم إنشاؤه من مصدر آمن للتشفير؛ هذه عمليات فحص منفصلة يتم إجراؤها بواسطة منطق التطبيق الخاص بك. الشكل الجيد ليس هو نفسه الحقيقي. قد لا تحدد السلسلة UUID التي يتم تحليلها بشكل صحيح وفقًا لشكلها أي صف في قاعدة البيانات الخاصة بك.

إن التصميم الجيد ليس حقيقيًا - لماذا قد لا يوجد UUID المثالي من الناحية النحوية في بياناتك، ولماذا لا يجب أن يكون المدقق أبدًا طبقة التفويض الخاصة بك

أ UUID التي تم تشكيلها بشكل مثالي ربما تم تخمينها أو نسخها ولصقها بشكل غير صحيح. التحقق من صحة التنسيق هو البوابة الأولى؛ الشيكات وجود والتحقق من الترخيص هي الثانية والثالثة. يعد إجراء بحث في قاعدة البيانات عن كل إدخال غير صالح للتنسيق أمرًا مهدرًا؛ يؤدي رفض الإدخال غير الصالح للتنسيق قبل استعلامات قاعدة البيانات إلى توفير الوقت. ال ToolAcre معيار مخرجات المولد 36-UUIDs للأحرف؛ إذا كنت تقوم ببناء أداة التحقق الخاصة بك، فاقبل المتغيرين Braced وUrn: لمطابقة مدخلات العالم الحقيقي، وارفض السلاسل التي تفشل في قواعد الشكل الأساسية قبل طلب قاعدة البيانات الخاصة بك. يتطلب تنفيذ أداة التحقق الصارمة تعبيرات عادية ومعالجة حالة الحافة. النموذج الأساسي واضح ومباشر: /^[0-9أ-و]{8}-[0-9أ-و]{4}-[0-9أ-و]{4}-[0-9أ-و]{4}-[0-9أ-و]{12}$/i (حساسة لحالة الأحرف). يضيف النموذج ذو الأقواس المتعرجة: /^\{[0-9أ-و]{8}-[0-9أ-و]{4}-[0-9أ-و]{4}-[0-9أ-و]{4}-[0-9أ-و]{12}\}$/i. يضيف المتغير urn: مخططًا: /^urn:uuid:[0-9أ-و]{8}-[0-9أ-و]{4}-[0-9أ-و]{4}-[0-9أ-و]{4}-[0-9أ-و]{12}$/i.

ما لا يغطيه هذا هو تسوية المعرفات للتخزين واختيار نوع العمود، وهما قراران منفصلان

يعتبر التعبير العادي الذي يتعامل مع جميع المتغيرات أقل قابلية للقراءة ولكنه ممكن. تقوم معظم أدوات التحقق من الصحة بالتطبيع أولاً: الأقواس الشريطية وurn: البادئة، وتحويلها إلى أحرف صغيرة، ثم مطابقة النمط المتعارف عليه. يمكن التحقق من الإصدار والبتات المتغيرة بعد مطابقة النمط عن طريق فحص الموضع 14 والموضع 19 كما هو موضح في مقالة 403. يعد التعامل مع الإدخال غير الصالح بأمان جزءًا من تصميم التحقق من الصحة. عندما يرسل العميل UUID بشكل غير صحيح، لا تكشف عن نمط التعبير العادي أو قواعد التحقق من الصحة الداخلية في رسالة الخطأ. قم بإرجاع خطأ واضح: "تنسيق UUID غير صالح. تنسيق 8-4-4-4-12 المتوقع، مثل 550e8400-e29b-41d4-a716-446655440000 " لا تحاول تصحيح الإدخال؛ اطلب من العميل إعادة الإرسال.

الخلاصة: التحقق من صحة الشكل مبكرًا، والبحث عن الوجود بشكل منفصل — يؤكد الاختيار ToolAcre الشكل في المتصفح قبل لمس قاعدة البيانات

تقوم بعض الأنظمة بتسجيل إدخالات غير صالحة للتدقيق الأمني ​​(اكتشاف محاولات الحقن أو هجمات ارتباك التنسيق). يرفض المدقق ToolAcre النماذج غير الأساسية التي تحتوي على رسالة خطأ واضحة ولا يحاول التصحيح التلقائي. لماذا يهم الشكل الأساسي لقابلية التشغيل البيني: إذا قام أحد الأنظمة بتخزين UUID كنظام سداسي عشري بدون واصلة وقام نظام آخر بتخزينها كرقم أساسي 8-4-4-4-12، فإن مقارنتها بالمساواة تتطلب التطبيع. تتطلب الأحرف الكبيرة والأحرف الصغيرة مقارنة غير حساسة لحالة الأحرف. تستعد مقابل عارية يتطلب تجريد. تجعل هذه الاختلافات العمليات المجمعة (الاستيراد والترحيل والمقارنات) أكثر صعوبة. الأدوات القياسية التي تنتج الشكل الأساسي تقلل الاحتكاك. يقوم المولد ToolAcre دائمًا بإخراج النموذج الأساسي ذو الأحرف الصغيرة 36؛ عندما تقوم باستيراد UUIDs من أنظمة أخرى، قم بتطبيعها مع هذا النموذج في عملية ETL الخاصة بك لضمان الاتساق.