لماذا الخاص بك JWT تنتهي صلاحيته على الفور: تنتهي مدة الصلاحية بالثواني، وليس بالمللي ثانية

تم إصداره في 10:00، وانتهت صلاحيته في 10:00 - تم رفض الرمز المميز عند أول استخدام له ولم تكن ساعة الخادم هي المشكلة

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

استخدم رمزًا مميزًا أو منقحًا لأن الرمز المميز لحامله هو بيانات اعتماد. يقرأ جهاز فك ترميز ToolAcre JWT بيانات الحمولة ولكنه لا يتحقق من التوقيعات عمدًا. انسخ المطالبة الزمنية الرقمية إلى محول الطابع الزمني فقط بعد الحفاظ على أداة الاختبار الأصلية وعمرها المقصود.

ما يقوله RFC 7519 - التاريخ الرقمي بالثواني منذ 1970-01-01T00:00:00Z، ولماذا هو رقم وليس سلسلة

تنص المقالة JWT المنشورة المجاورة بالفعل على العقد المهم: `exp` يقوم NumericDate بحساب الثواني من عصر Unix. إن تكرار شرح المعايير لن يضيف أي قيمة هنا. والسؤال العملي هو ما إذا كان كل منتج ومُسلسل ومدقق وأداة اختبار يحترم نفس المقياس.

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

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

تحدد المقالة JWT الموجودة NumericDate الثواني؛ تنطبق هذه المقالة هذه الحقيقة على تصحيح الأخطاء انتهاء الصلاحية

إذا فسر المدقق مطالبة الثواني الصالحة بالمللي ثانية، فإن التاريخ يقع بالقرب من 1970 ويبدو منتهي الصلاحية. إذا كتب المُصدر قيمة مللي ثانية حالية في حقل يتم تفسيره لاحقًا على أنه ثوانٍ، فإن انتهاء الصلاحية يتحرك إلى ما هو أبعد من العمر المقصود أو خارج النطاق المدعوم للمكتبة. يحدد العرض الذي يظهر الجانب الذي يملك خطأ المقياس.

تجنب "الإصلاح" الذي يقبل كلا النموذجين بناءً على عدد الأرقام. يؤدي ذلك إلى تحويل الرموز المميزة المشوهة إلى بروتوكول بديل دائم ويمكن أن يخفي تراجعات جهة الإصدار. ارفض القيم التي تنتهك عقد NumericDate الخاص بالتطبيق، وقم بالإنشاء الصحيح، وأضف التركيبات التي تميز الثواني عن المللي ثانية.

يمكن أن تؤدي أخطاء المللي ثانية إلى رفض فوري أو انتهاء صلاحية بعيد بشكل غير معقول اعتمادًا على الجانب الخطأ

قم بفك تشفير الحمولة لكشف `exp`، `iat` و `nbf` كقيم أولية قبل أن يقوم إطار العمل بتحويلها. قارن `exp − iat` بعمر الرمز المميز المقصود بالثواني. تحقق من `nbf` بشكل منفصل؛ يمكن أن يكون الرمز غير منتهي الصلاحية ولكنه غير قابل للاستخدام. لا تستنتج الأصالة من الأوقات المعقولة المظهر.

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

مثال عملي: تجربة 1700003600 - تحويلها إلى UTC والتوقيت المحلي، والتحقق منها مقابل iat، والتأكد من العمر هو ما كنت تقصده

بالنسبة إلى `iat = 1,700,000,000` و`exp = 1,700,003,600`، ينتج عن عملية الطرح 3,600 ثانية، أو ساعة واحدة. يقرأ المحول انتهاء الصلاحية بشكل صريح بالثواني ويعيد `2023-11-14T23:13:20.000Z`؛ وقت الإصدار هو `2023-11-14T22:13:20.000Z`.

هذه الأرقام فريدة من نوعها بالنسبة للمثال التشخيصي لهذه المقالة. إذا أدى تحديد المللي ثانية إلى قراءة 1970 لشهر يناير، فهذا دليل متوقع على المقياس الخاطئ. تأكد من أن الوقت الحالي للمدقق يتم التعبير عنه أيضًا بالثواني قبل الانتهاء من تنفيذ سياسة الساعة الواحدة بشكل صحيح.

يتم حساب الفارق لمدة ساعة واحدة قبل التنسيق، بحيث يبقى ساعة واحدة في كل منطقة. قد تختلف شاشات العرض المحلية، لكن `exp − iat` لا يختلف.

مثال عملي: قارن exp 1,700,003,600 مع iat قريب باستخدام الثواني الصريحة

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

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

إذا تم تكوين التسامح، فاختبر القيم داخل وخارج تلك الحدود في ثوانٍ. وهذا يثبت السياسة بشكل مستقل عن أي عرض للتاريخ أو اللغة.

لا يمكن للتسامح إصلاح عامل عدم التطابق 1,000

لا يمكن لتحويل الطابع الزمني التحقق من توقيع الرمز المميز أو الخوارزمية المسموح بها أو المفتاح أو المصدر أو الجمهور. حتى المطالبة المستقبلية المنسقة بشكل مثالي `exp` قد تكون موجودة داخل رمز مميز مزور. يتميز جهاز فك التشفير JWT بالشفافية عن عمد بشأن هذه الحدود ويجب إقرانه بأداة تحقق موثوقة.

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

يجب أن يتم فك التشفير فقط مع التركيبات الاصطناعية أو المنقحة بأمان أثناء التصحيح الروتيني. يؤدي نسخ بيانات اعتماد حاملها المباشر إلى حدوث مشكلة أمنية لا علاقة لها بحساب الطابع الزمني.

الوجبات الجاهزة: EXP يتكون من عشرة أرقام، وليس ثلاثة عشر - وكيف يوجد وحدة فك التشفير JWT ومحول الطابع الزمني Unix في نفس علامة التبويب حتى تتمكن من التحقق من المطالبة في ثوانٍ

تعامل مع مطالبات الوقت JWT بالثواني عند كل حد واختبر اختلافاتها كمدد. يقوم محول الطابع الزمني بتحويل مطالبة فردية إلى UTC وسياق محلي؛ يكشف جهاز فك التشفير JWT عن الرقم الأولي. يشرحون معًا التوقيت دون ادعاء الثقة.

ينتمي التصحيح الدائم إلى إصدار رمز التحقق، وليس إلى دليل تشغيل الدعم الذي يقوم بتبديل الوحدات حتى يعمل الرمز المميز. احتفظ بالثواني الصريحة، ورفض المقياس المشوه، واحتفظ بالتحقق من التوقيع كقرار إلزامي منفصل.

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