نقل تكامل reCAPTCHA من 2Captcha إلى solvethree

يغطي هذا الانتقال reCAPTCHA v3 Enterprise عبر 2Captcha API v2. ولا يشرح واجهة API القديمة in.php/res.php. كذلك، فإن إصدار API الخاص بـ 2Captcha ليس إصدار CAPTCHA: إذ لا يدعم solvethree خدمة reCAPTCHA v2.

يستخدم الطلب الأولي الغلاف الموثّق في إنشاء مهمة في 2Captcha: بيانات اعتماد خارج كائن مهمة خاص بالمزوّد.

{
  "clientKey": "TWO_CAPTCHA_API_KEY",
  "task": {
    "type": "RecaptchaV3TaskProxyless",
    "websiteURL": "https://accounts.example.com/login",
    "websiteKey": "PUBLIC_SITE_KEY",
    "minScore": 0.7,
    "pageAction": "login",
    "isEnterprise": true
  }
}

لا تنقل هذا الكائن إلى واجهة API الجديدة دون تعديل. وعلى وجه الخصوص، لا مكان لنوع المهمة بلا وكيل ولا لحقل minScore في طلب solvethree أدناه.

أولًا، أعِدّ الموقع المستهدف في لوحة تحكم solvethree. تحتاج مساحة عملك إلى ملف تعريف موقع نشط قبل أن تتمكن من حل الطلبات لاسم المضيف هذا. إرسال اسم مضيف وإجراء لا ينشئ ملف تعريف.

أنشئ مهام جديدة عبر POST /v1/tasks على https://api.solvethree.com، باستخدام Authorization: Bearer مع مفتاح API لمساحة عملك. احتفظ بهذا المفتاح على الخادم. يستخدم عقد إنشاء المهام جسم JSON مسطحًا بدلًا من كائن task متداخل.

{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "example_login_001"
}

استبدل اسم المضيف والإجراء والوكيل في المثال بقيم الموقع المستهدف. اختر requestId قبل إرسال الطلب واحتفظ به للاسترداد عند انتهاء المهلة؛ واستخدم قيمة جديدة لكل مهمة منطقية جديدة.

يستخدم المثال وكيلًا واحدًا. ويمكن بدلًا من ذلك استخدام proxyCandidates، الذي يقبل اثني عشر عنوان URL مختلفًا لوكلاء HTTP أو HTTPS كحد أقصى، من دون مسارات أو استعلامات أو أجزاء. أرسل أحد الحقلين، وليس كليهما أبدًا. تتيح الخيارات المرشحة للخدمة تجربة نقاط خروج بديلة؛ لكنها لا تضمن وجود وكيل يعمل.

أبقِ مهام 2Captcha قيد التنفيذ ضمن آلية getTaskResult الخاصة بها، باستخدام بيانات اعتمادها ومعرّفات مهامها وسياسة الاستقصاء الموثقة لديها. معرّف مهمة من خدمة أخرى ليس مرجعًا لمهمة solvethree.

1. 1.

   معالجة استجابة الإنشاء

   تحقّق من أن استجابة HTTP لا تشير إلى عدم النجاح قبل قراءة حمولة النجاح. ينتظر إنشاء reCAPTCHA مدة تصل إلى 15 ثانية افتراضيًا، لكنه قد يُرجع مهمة لم تصل إلى حالة نهائية. إذا كانت حالتها ready بالفعل، فاستخدم الحل دون بدء حلقة استقصاء.

2. 2.

   استقصاء المهام غير المكتملة فقط

   استرجع مهمة solvethree عبر GET /v1/tasks/:id. استبدل التحقق القديم من processing بالتحقق من pending وsolving؛ فكلاهما يعني أن المهمة لم تكتمل. وحدها ready تتضمن حلًا قابلًا للاستخدام.

3. 3.

   تحديد الانتظار في عنوان URL

   لا ينتظر الاستقصاء عبر GET افتراضيًا. للاستقصاء الطويل، اضبط معلمة الاستعلام waitMs في عنوان URL على 15000 كحد أقصى، وليس كحقل JSON. اضبط مهلة عميل HTTP بحيث تستوعب مدة الانتظار المطلوبة إضافةً إلى الوقت الإضافي للشبكة.

4. 4.

   التوقف عند failed

   اقرأ errorCode وerror، ثم أوقف استقصاء تلك المهمة. تُردّ رسوم عمليات الحل الفاشلة. يتطلب خطأ مثل site-unreachable التحقيق؛ فلا تفترض أن كل فشل سببه مشكلة في الرصيد، ولا تواصل إعادة إرسال مدخلات غير صالحة دون تغيير.

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

افصل أخطاء HTTP عن حالات الفشل النهائية للمهام في طبقة التكامل. يوضح عقد الاستقصاء ومعالجة الفشل هذين المسارين؛ ولا تُعِد استخدام محلّل حمولة الأخطاء الخاص بـ 2Captcha.

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

استخدم هوية المتصفح المُرجعة في userAgent وsecChUa، مع الوكيل الذي نجح، عند إرسال الرمز. إذا قدّمت proxyCandidates، فاستخدم الوكيل الذي نجح بدلًا من اختيار وكيل مرشح آخر للإرسال.

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