GitHub يعتمد رموز تثبيت التطبيقات عديمة الحالة افتراضياً ويطيلها إلى نحو 520 حرفاً

أكمل GitHub الطرح التدريجي لصيغة رموز تثبيت GitHub Apps عديمة الحالة، وأصبحت هذه الصيغة هي الافتراضية لجميع الرموز الجديدة التي تُنشأ للتطبيقات المؤهلة.

الرمز الجديد يأتي بصيغة ghs_APPID_JWT، وهي صيغة تساعد GitHub على إصدار الرموز والتحقق منها بسرعة أكبر، بما يدعم موثوقية GitHub API. والمقصود بـ«عديم الحالة» هنا أن التحقق من الرمز لا يعتمد بالطريقة نفسها على حفظ حالته في جهة خادمية منفصلة.

أبرز تغيير ستلاحظه الفرق هو الطول: لا تزال رموز التثبيت تبدأ بالبادئة ghs_، لكنها أصبحت بطول يقارب 520 حرفاً بدلاً من 40 حرفاً في الصيغة السابقة.

ولا يغيّر ذلك آلية الصلاحيات أو نطاق الوصول:

• تبقى صلاحيات الرمز كما تُحدَّد للتطبيق.
• يبقى تقييد الوصول إلى مستودعات محددة كما هو.
• تبقى مدة صلاحية الرمز ساعة واحدة.
• لا يتغير مسار REST API المستخدم لإنشاء رمز الوصول الخاص بالتثبيت.
• الرموز التي أُنشئت قبل التغيير ستظل صالحة حتى انتهاء مدتها.

ما الذي ينبغي مراجعته؟

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

• تحقق برمجي يشترط أن يكون الرمز بطول 40 حرفاً، أو يعتمد تعبيراً نمطياً للصيغة القديمة.
• حقول قواعد بيانات أو مخازن أسرار أو متغيرات بيئة لا تستوعب الطول الجديد.
• وسيطات مثل proxies أو بوابات API أو middleware قد تقص ترويسات Authorization الطويلة أو ترفضها.
• قواعد تسجيل السجلات وإخفاء الأسرار التي لا تتعرف إلا على نمط الرمز القديم.

كان GitHub قد وفر ترويسة طلب مؤقتة باسم X-GitHub-Stateless-S2S-Token لاختبار الصيغة الجديدة عند الحاجة. ستتوقف GitHub عن احترام هذه الترويسة في 30 نوفمبر 2026؛ لذلك ينبغي إزالة استخدامها من بيئات الإنتاج بعد التأكد من توافق التطبيقات ومسارات العمل مع الصيغتين.