المهمة جاهزة. لماذا يُرفض رمز reCAPTCHA؟

{
  "id": "example-task",
  "status": "ready",
  "solution": {
    "token": "EXAMPLE_TOKEN",
    "userAgent": "EXAMPLE_USER_AGENT",
    "secChUa": "EXAMPLE_CLIENT_HINTS"
  }
}

في هذا المثال، solution.token هي القيمة التي يجب إرسالها حيثما يتوقع الموقع المستهدف رمز reCAPTCHA الخاص به. يحدّد id مهمة solvethree؛ وليس رمزًا. ولا ترسل كائن الحل كاملًا أيضًا.

افحص الطلب الصادر النهائي، لا المتغيّر الذي يحتوي على الاستجابة فحسب. تحقّق من احتوائه على الرمز الحالي، لا قيمة فارغة أو رمز أقدم متبقٍّ في النموذج. أبقِ الرموز خارج السجلات المشتركة.

الرمز المُرسل صحيح، لكن الموقع المستهدف لا يزال يرفضه.

قارن اسم مضيف الموقع في المهمة باسم مضيف الطلب المحمي. تحقّق من وجود نطاق فرعي أو بيئة مختلفة.

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

يُستخدم رمز طُلب لتفاعل معين في تفاعل آخر.

قارن action في المهمة بالقيمة الدقيقة المتوقعة لهذا الطلب المحمي.

جرّب هذا: استخدم action المرتبط بالتفاعل الذي ترسله.

يستخدم التكامل نوعًا غير صحيح من reCAPTCHA.

افحص recaptchaType في طلب المهمة. قيمته الافتراضية enterprise-v3؛ وتقبل البوابة أيضًا v3.

جرّب هذا: حدّد صراحةً المنتج المطابق لما تستخدمه الوجهة. بالنسبة إلى Enterprise v3، استخدم enterprise-v3.

تنتهي صلاحية رموز استجابة المواقع لكل من reCAPTCHA الكلاسيكي وreCAPTCHA Enterprise بعد دقيقتين، ولا تُستخدم إلا مرة واحدة. يمكن التحقق من الرموز الكلاسيكية مرة واحدة، وتقييم رموز Enterprise مرة واحدة. نفّذ الحل قبيل الطلب المحمي بدلًا من الاحتفاظ بمخزون من الرموز الجاهزة.

• إذا تأخر الإرسال، فتحقق من الوقت المنقضي بين الحل وإرسال الرمز.
• إذا سبق التحقق من الرمز أو تقييمه، فلا تُعِد استخدامه في إرسال آخر.
• لا تُجرِ تحققًا منفصلًا أو تقييم Enterprise لمجرد اختبار الرمز قبل إرساله إلى الوجهة. فقد يستهلك ذلك الاختبار الرمز.

ينجح الحل، لكن الإرسال يستخدم اتصالًا آخر.

قارن الوكيل الذي نجح في الحل بالوكيل المستخدم للطلب المحمي. إذا قدّمت proxyCandidates، فلا تفترض أن المرشح الأول هو الذي نجح.

جرّب هذا: أرسل عبر الوكيل الذي نجح. قد يؤدي تغيير عنوان IP بين الحل والإرسال إلى فشل الطلب.

يستخدم العميل المُرسِل ترويسات المتصفح الافتراضية الخاصة به.

قارن قيمتي User-Agent وSec-CH-UA الصادرتين مع solution.userAgent وsolution.secChUa.

جرّب هذا: استخدم هوية المتصفح المُعادة مع الوكيل الذي نجح. لا تجمع الرمز مع قيم user-agent أو client-hint غير المرتبطة به.

افحص متن استجابة الوجهة إلى جانب حالة HTTP. لا تحدد حالة 403 وحدها آلية الحماية التي رفضت الطلب. ابحث عن خطأ صريح في الرمز أو عدم تطابق في اسم المضيف أو action قبل طلب رمز آخر.

إذا توفرت تفاصيل التحقق، فافحص نتيجة success في reCAPTCHA الكلاسيكي ومعلومات السياق والأخطاء المُعادة. بالنسبة إلى Enterprise، افحص صلاحية الرمز وأسباب التقييم ذات الصلة. لا تفترض أن الدرجة وحدها تفسر الرفض؛ فالموقع هو الذي يقرر كيفية استخدام التقييم.

إذا ظل السبب غير واضح، فتواصل مع [email protected] وأرفق معرّف المهمة وrequestId إن استُخدم، والمنتج، والطابع الزمني، واسم مضيف الوجهة وaction، وحالة HTTP أو خطأ المهمة، ووصفًا للاستجابة منزوع المعلومات الحساسة. احذف مفاتيح API وكلمات مرور الوكلاء والرموز وملفات تعريف الارتباط وبيانات العملاء.