reCAPTCHA Enterprise مقابل Standard: ما الذي يتغيّر فعلياً

انتقال موقع من reCAPTCHA القياسي إلى reCAPTCHA Enterprise لا يغيّر شيئاً في ما يراه الزائر، لكنه يغيّر ثلاثة أشياء في جانبك التقني: مفتاح الموقع، ونقطة النهاية التي يتحقق منها الخادم، وشكل الاستجابة التي يقرأها فريق الأمان. أما في استدعاء CaptchaAI فالفارق كله معامل واحد اسمه enterprise.

والمشكلة العملية أن هذا الانتقال نادراً ما يُعلَن. الفريق يكتشفه عادةً حين تبدأ سكربتات الأتمتة في تلقّي رفض متكرر رغم أن الرمز يعود سليماً، أو حين يلاحظ أحدهم أن ملف api.js صار enterprise.js. في السطور التالية: كيف تتحقق من النسخة خلال دقيقة، وما الذي يتغيّر في التقييم والاستجابة، وكيف تضبط طلبك في الحالتين.

لماذا تنتقل المواقع إلى Enterprise أصلاً

الإصدار القياسي مجاني ويكفي معظم المواقع. من يدفع مقابل Enterprise يفعل ذلك لأسباب إدارية وأمنية، وكل سبب منها يترك أثراً تقنياً تراه من الخارج:

• التكامل مع WAF — ربط reCAPTCHA بطبقة Cloudflare أو Akamai أمام التطبيق.
• تحليلات أدق — لوحة تعرض اتجاهات المخاطر وأنماط الطلبات المشبوهة.
• قواعد مخصصة — عتبة مستقلة لكل إجراء: تسجيل الدخول، الدفع، إنشاء الحساب.
• الامتثال — اتفاقية مستوى خدمة وخيارات لإقامة البيانات داخل نطاق جغرافي.
• حماية الحساب — كشف تسرّب كلمات المرور ومحاولات الاستيلاء على الحسابات.

الخلاصة التي تهمّك: العتبة تصبح مختلفة لكل إجراء داخل الموقع الواحد. المسار الذي يمرّ عند تسجيل الدخول قد يُرفض عند إتمام الشراء، ولا علاقة لذلك بجودة الرمز الذي حصلت عليه.

جدول الفروق بين النسختين

يجمع الجدول التالي ما يهمّك من الفروق، من التسعير عند Google إلى شكل الإدارة والتحقق:

آخر صفّين هما الأهم لك: النسختان تدعمان v2 وv3 معاً، فالسؤال ليس أي إصدار تحلّ بل أي نسخة تستدعيها الصفحة.

ما الذي يتغيّر في الاستجابة والتقييم

النسختان تُعيدان نتيجة بين 0.0 و1.0، والفرق ليس في الرقم بل في ما يرافقه.

استجابة الإصدار القياسي

{
  "success": true,
  "score": 0.7,
  "action": "login",
  "challenge_ts": "2024-01-15T12:00:00Z",
  "hostname": "example.com"
}

استجابة Enterprise

{
  "tokenProperties": {
    "valid": true,
    "action": "login",
    "createTime": "2024-01-15T12:00:00Z",
    "hostname": "example.com"
  },
  "riskAnalysis": {
    "score": 0.7,
    "reasons": ["LOW_CONFIDENCE_SCORE"],
    "extendedVerdictReasons": []
  },
  "event": {
    "token": "...",
    "siteKey": "...",
    "expectedAction": "login"
  }
}

مصفوفة reasons هي الإضافة الحقيقية: هي التي تخبر الموقع لماذا جاءت النتيجة على هذا النحو، فيُبنى القرار الأمني عليها بدل مقارنة رقم واحد بعتبة ثابتة. أما من جانبك فلا يتغيّر شيء في ما يستقبله النموذج؛ حقل g-recaptcha-response يبقى كما هو في الحالتين.

رموز الأسباب تصف بيئة الطلب ونمطه، لا الرمز الذي أرسلته. لذلك تُقرأ كمؤشر على ما يراه الموقع من جانبه، وليست تقييماً لجودة الحل.

كيف تتعرّف على Enterprise من داخل صفحة الموقع

افتح مصدر الصفحة وامرر على أربعة مؤشرات بالترتيب:

1. ملف السكربت — api.js يعني الإصدار القياسي، وenterprise.js يعني Enterprise.
2. دالة التنفيذ — grecaptcha.execute() مقابل grecaptcha.enterprise.execute().
3. واجهة تحقق الخادم — نقطة النهاية siteverify مقابل recaptchaenterprise.googleapis.com.
4. مكان الإدارة — لوحة إدارة reCAPTCHA مقابل Google Cloud Console.

المؤشر الأول وحده يحسم الأمر في أغلب الحالات:

// Standard
<script src="https://www.google.com/recaptcha/api.js?render=SITEKEY"></script>

// Enterprise
<script src="https://www.google.com/recaptcha/enterprise.js?render=SITEKEY"></script>

انتبه إلى أن الرمز العائد لا يحمل أي إشارة إلى النسخة المستخدمة؛ الفحص يتم من الصفحة، لا من الرمز نفسه. ومفتاح الموقع لا يُنقل بين النسختين: مفاتيح Enterprise تُنشأ داخل Google Cloud Console وتختلف عن مفاتيح الإصدار القياسي.

إرسال الطلب إلى CaptchaAI في الحالتين

بعد أن عرفت النسخة يصبح الباقي إعداداً بسيطاً: أرسل الطلب إلى in.php ثم استفسر عن النتيجة من res.php كالمعتاد، وأضف المعامل enterprise بقيمة 1 فقط حين تكون الصفحة تحمّل ملف enterprise.js.

الإصدار v3: الطلب قبل المعامل وبعده

هذا هو الطلب القياسي كما تكتبه اليوم:

resp = requests.get("https://ocr.captchaai.com/in.php", params={
    "key": API_KEY, "method": "userrecaptcha", "version": "v3",
    "googlekey": SITEKEY, "action": "login", "pageurl": URL, "json": 1
})

والطلب نفسه على صفحة تحمّل enterprise.js — سطر واحد إضافي لا غير:

resp = requests.get("https://ocr.captchaai.com/in.php", params={
    "key": API_KEY, "method": "userrecaptcha", "version": "v3",
    "enterprise": 1,  # Only difference
    "googlekey": SITEKEY, "action": "login", "pageurl": URL, "json": 1
})

الإصدار v2: الطلب قبل المعامل وبعده

في v2 لا وجود لمعامل action أصلاً، فيأتي الطلب أقصر:

resp = requests.get("https://ocr.captchaai.com/in.php", params={
    "key": API_KEY, "method": "userrecaptcha",
    "googlekey": SITEKEY, "pageurl": URL, "json": 1
})

وبإضافة المعامل نفسه على موقع يعمل بـ Enterprise:

resp = requests.get("https://ocr.captchaai.com/in.php", params={
    "key": API_KEY, "method": "userrecaptcha",
    "enterprise": 1,
    "googlekey": SITEKEY, "pageurl": URL, "json": 1
})

القاعدة الوحيدة التي تستحق الانتباه هنا تخصّ v3: مرّر قيمة action مطابقة حرفياً لما تستدعيه الصفحة، فاختلاف حرف واحد يكفي لخفض النتيجة.

سيناريو عملي: بوابة حجز في الرياض

تخيّل فريق اختبار جودة يشغّل تجارب ليلية معتمدة على بوابة حجز في الرياض تدعم ثلاث لغات وواجهة RTL. كانت الاختبارات مستقرة لأشهر، ثم بدأت خطوة تسجيل الدخول وحدها بالفشل بينما تنجح خطوة البحث. هذا النمط تحديداً — فشل إجراء واحد دون بقية الإجراءات — توقيع مألوف لـ Enterprise: الموقع رفع عتبة إجراء login بعد موجة محاولات آلية، وترك ما عداه على حاله.

التشخيص لا يستغرق أكثر من دقيقة:

1. افتح مصدر صفحة تسجيل الدخول وابحث عن enterprise.js.
2. قارن قيمة action في السكربت بما يرسله اختبارك حرفاً بحرف.
3. أضف enterprise: 1 إلى الطلب، أو ولّد مفتاح موقع من Google Cloud Console إن كانت البوابة ملك فريقك.

يبقى سؤال الميزانية، وهو أكثر ما يتكرر في هذا السياق: فوترة CaptchaAI قائمة على عدد الـ threads المتزامنة لا على عدد عمليات الحل، مع عدد غير محدود من عمليات الحل داخل الشهر، ودون رسوم إضافية بحسب نوع الـ CAPTCHA. فريق يشغّل خمسة مسارات متوازية يبقى ضمن خطة BASIC بسعر $15 شهرياً و5 threads، بينما تحتاج بوابة تشغّل عشرات المسارات في وقت واحد إلى ADVANCE بسعر $90 شهرياً و50 thread. الأسعار معلنة بالدولار الأمريكي على صفحة تسعير CaptchaAI.

أسئلة شائعة

هل تكلفة التعامل مع Enterprise أعلى من الإصدار القياسي؟

الخطة نفسها تغطي الحالتين. الفوترة مرتبطة بعدد الـ threads المتزامنة في خطتك مع عدد غير محدود من عمليات الحل شهرياً، ولا توجد رسوم إضافية مرتبطة بنوع الـ CAPTCHA داخل الخطة.

ماذا يحدث إذا نسيت المعامل على موقع يعمل بـ Enterprise؟

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

ما العتبة المناسبة للنتيجة؟

لا توجد قيمة صحيحة واحدة، و0.5 مجرد نقطة انطلاق شائعة. ميزة Enterprise أنها تتيح عتبة مستقلة لكل إجراء:

• البحث والتصفح: عتبة متساهلة قريبة من 0.3.
• تسجيل الدخول وإتمام الشراء: عتبة أعلى قريبة من 0.7.

راجع رموز الأسباب قبل رفع العتبة، فهي تكشف إن كانت المشكلة في بيئة التشغيل لا في سلوك المستخدم.

هل يختلف حقل الرمز أو نقطة الإرسال بين النسختين؟

لا. حقل الرمز داخل النموذج يبقى g-recaptcha-response، والإرسال إلى in.php والاستفسار من res.php كما هو. ما يختلف هو نقطة تحقق الخادم لدى الموقع: siteverify في القياسي مقابل recaptchaenterprise.googleapis.com في Enterprise.

وإذا انتقل الموقع إلى نظام حماية مختلف تماماً؟

لا يدعم CaptchaAI حالياً hCaptcha ولا FunCaptcha، ولم يصبح دعم GeeTest v4 متاحاً بعد وهو معلن كـ«قريباً». المتاح فعلياً يشمل reCAPTCHA v2 وv3 بنسختيهما القياسية وEnterprise، إضافة إلى GeeTest v3 وCloudflare Turnstile وCloudflare Challenge والصور النصية والشبكية.

أدلة ذات صلة

• ابدأ مع CaptchaAI: أول عملية حل خلال دقائق
• حلّ reCAPTCHA v2 عبر الـ API خطوة بخطوة