GitHub غيّر طول التوكن: افحص تطبيقك قبل 27 أبريل

هنا بنقبل تغير الصيغة، لكن بنحط حد دفاعي كبير ضد مدخلات غريبة. الـ trade-off هنا إنك تفقد validation ضيق كان شكله مطمئن، مقابل إن التطبيق يبقى متوافق مع تغييرات GitHub القادمة.

عدّل التخزين قبل rollout

لو عندك PostgreSQL، استخدم TEXT بدل VARCHAR(64) لتوكنات الوصول. الفرق العملي في PostgreSQL مش كبير من ناحية التخزين، لكنك بتزيل قيد غير مفيد. مثال migration بسيط:

لو عندك MySQL، استخدم TEXT أو VARCHAR(2048) حسب نمط الفهارس عندك. لا تعمل index مباشر على التوكن نفسه. لو محتاج lookup، خزّن hash منفصل مثل SHA-256 وابحث به. الافتراض إنك لا تحتاج مقارنة التوكن الخام في queries عادية.

سيناريو واقعي: شركة عندها GitHub App داخلي يثبت على 300 repository ويولد installation token كل ساعة. لو 2% من عمليات التجديد بدأت تفشل بسبب column قصيرة، هتشوف 6 repos تقريبًا في كل دورة بدون checks أو sync. ده كفاية يوقف merge pipeline لفريق كامل.

اختبار سريع قبل الإنتاج

اعمل test بتوكن وهمي بنفس الشكل المتوقع. لا تحتاج توكن حقيقي. المطلوب إنك تختبر التخزين، النقل بين الخدمات، logging، والـ validation:

بعدها مرر القيمة في مسار staging: API request، job queue، database write، ثم read. القياس المطلوب بسيط: طول التوكن بعد القراءة لازم يساوي طول التوكن قبل التخزين. لو دخل 511 وخرج 64، عندك قص في مكان ما.

ما الذي سيتغير وماذا لن يتغير

• التغيير يبدأ تدريجيًا من 27 أبريل إلى منتصف مايو 2026 لتوكنات GitHub Actions وبعض التكاملات الأولى.
• من منتصف مايو إلى أواخر يونيو 2026 يبدأ التوسع على كل GitHub App installation tokens.
• توكنات GitHub Enterprise Server ليست ضمن نطاق التغيير الحالي حسب إعلان GitHub.
• التوكنات الموجودة حاليًا ستظل تعمل حتى انتهاء صلاحيتها.
• توكن installation access token عادةً ينتهي بعد ساعة حسب وثائق GitHub.

الطريقة الشائعة الغلط هنا هي محاولة parse للـ JWT الداخلي أو الاعتماد على claims بداخله. ده بيخلق coupling مع تفاصيل GitHub الداخلية. استخدم GitHub API للتحقق من الصلاحيات والنتائج بدل ما تبني منطق أمني على شكل التوكن.

متى لا تستخدم هذه الطريقة

لا تحتاج migration كبير لو أنت تستخدم Octokit SDK فقط ولا تخزّن التوكن ولا تعمل regex عليه ولا تمرره عبر systems بحد طول صغير. كمان لو كل بيئتك GitHub Enterprise Server فقط، فالإعلان الحالي لا يطبق عليها. لكن حتى هنا، فحص rg يستحق 10 دقائق لأنه يكشف ديون تقنية قديمة.

لا تستخدم TEXT بدون حد منطقي لو عندك API عام يستقبل التوكن من مستخدم. في الحالة دي حط حد مثل 2048 حرفًا، وسجّل الطول فقط في logs وليس التوكن نفسه. المكسب أمان وتشخيص أفضل. التكلفة إنك تضيف validation واضح وتحدّث tests.

مصادر

• GitHub Changelog: Notice about upcoming new format for GitHub App installation tokens
• GitHub Docs: Generating an installation access token for a GitHub App
• GitHub Docs: About authentication to GitHub

الخطوة التالية

افتح مستودع التكامل مع GitHub وشغّل أمر rg الموجود فوق. لو لقيت VARCHAR(64) أو regex ثابت، عدّلها اليوم قبل بداية rollout في 27 أبريل 2026.