لماذا يهمّ رمز API حتى لو كان «للسيرفر فقط»؟
رمز API للمتجر هو مفتاح يمثّل هوية المتجر أمام واجهات المنصّة الحسّاسة. إذا سُرّق، يمكن لطرف آخر محاولة التظاهر بأنه سيرفرك في طلبات التحقق — لذلك تُفرض حدود معدّل وربما ربط بـ IP. هذا المقال يشرح للمطوّر الذي يكتب التكامل كيف يفكّر في الأخطاء كحالات تشغيل وليس كـ«رسالة غامضة».
رؤوس الطلب التي يجب أن تكون ثابتة في ذهنك
X-Tenant-Id(أو الاسم المعتمد في منصّتك): يربط الطلب بمتجر محدد.Authorization: Bearer <tenant_api_token>: يثبت أن الطلب مرفوع من طرف يملك سر المتجر.- أحياناً
X-Device-Idأو حقول في جسم JSON للترخيص — راجع وثائق المنتج لنسختك الحالية.
ماذا يعني 429 عملياً؟
يعني أن المنصّة رأت كثافة طلبات أعلى من الحد المسموح للمتجر في النافذة الزمنية. الحل ليس «إعادة المحاولة فوراً بلا تأخير» بل تراجع يزداد زمنه (exponential backoff) مع سقف أعلى، وتقليل النداءات غير الضرورية (مثلاً لا تستدعِ التحقق من كل لاعب كل ثانية إن كانت النتيجة مخزّنة مؤقتاً على السيرفر لثوانٍ).
سجلات التدقيق من جهة التاجر
احتفظ في سيرفرك بسجل مختصر: وقت الطلب، نتيجة المنصّة، معرف الترخيص (وليس بالضرورة المفتاح كاملاً في السجل العام). يساعد ذلك عند شكوى عميل وعند مراجعة أمنية بعد تسريب محتمل.
تدوير الرمز بعد تسريب محتمل
- أوقف السيرفر مؤقتاً أو عطّل التحقق إن كان ذلك آمناً لبيئتك.
- اطلب من جهة الدعم الرسمية لمتجرك إصدار رمز API جديد عند التسريب أو التدوير (حسب سياسة مزوّد الخدمة لديك).
- حدّث قيمة السر في بيئة السيرفر واختبر طلباً واحداً ناجحاً قبل فتح البث للاعبين.
- راقب السجلات لطلبات تستخدم الرمز القديم — قد تكشف عن مهاجم ما زال يحاول.