فهم مسار التحقق من ترخيص FiveM بين السيرفر والمنصّة

أين يحدث التحقق فعلياً؟

في بنية منصّة تراخيص لـ FiveM، يوجد عادة ثلاث طبقات: لوحة التاجر حيث تُعرَّف المنتجات والمفاتيح، وواجهة HTTP على المنصّة تستقبل طلب التحقق من السيرفر، وسكربت السيرفر (مثل fivem_serverBoot.lua) الذي يقرأ الاستجابة ويقرر السماح بالتشغيل أو رفضه. فهم ترتيب هذه الطبقات يمنع لبساً شائعاً: «السكربت لا يتحدّث مع قاعدة بيانات التاجر مباشرة»، بل يمرّ عبر المنصّة حتى تُطبَّق سياسات الحدّ والتوقيع والربط بـ IP عند الحاجة.

ماذا يرسل السيرفر عادة؟

يُفترض أن يرسل السكربت معرّف المتجر (X-Tenant-Id أو ما يعادله في توثيق منصّتك)، ورمز API الخاص بالمتجر في ترويسة Authorization: Bearer …، ومفتاح الترخيص أو المعرف الذي يحدده منتجك. لا تُخزَّن أسرار التاجر في ملفات يمكن لأي لاعب قراءتها؛ استخدم متغيرات بيئة السيرفر أو convars آمنة.

لماذا يرتبط أحياناً التحقق بعنوان IP السيرفر؟

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

أخطاء شائعة في الإعداد

• خلط بين رمز API للمتجر وبين جلسة مستخدم في لوحة التاجر — التحقق من الترخيص للسيرفر لا يستخدم كوكيز المتصفح.
• تشغيل نسختين من السيرفر بنفس المفتاح دون فهم سياسة IP، فيظن التاجر أن المنصّة «معطّلة».
• طباعة الاستجابة الكاملة في سجلات العامة للاعبين، ما يكشف تفاصيل داخلية. اقتصر السجلات على رمز الحالة والمعرف الداخلي.

ما الذي يجب أن يوثّقه التاجر لفريق السيرفر؟

1. قيمة X-Tenant-Id الصحيحة لمتجره.
2. مصدر رمز API وكيفية تدويره عند التسريب.
3. هل المنتج يربط الترخيص بـ IP أم لا، وما الإجراء عند نقل السيرفر.
4. سياسة إعادة المحاولة عند 429 (تراجع أسيّ عنيد أفضل من إغراق المنصّة).