نقل تكامل reCAPTCHA من CapSolver إلى solvethree

يستخدم solvethree افتراضيًا reCAPTCHA v3 Enterprise، ويقبل أيضًا v3 القياسي. ومنتجاته العامة الأخرى هي Kasada وTicketmaster TMPT. لا يدعم reCAPTCHA v2 أو hCaptcha أو Turnstile أو الحل عبر إضافات المتصفح، لذا فهو ليس بديلاً شاملاً لكل تكاملات CapSolver.

قبل إرسال مهمة reCAPTCHA، أعدّ الموقع المستهدف في لوحة التحكم وتأكّد من توفّر ملف تعريفي نشط لمساحة عملك. إرسال اسم مضيف وإجراء لا ينشئ ذلك الملف التعريفي. لا تحذف حقل websiteKey الخاص بـ CapSolver وتفترض أن بقية الطلب كافية.

يستخدم الطلب الأولي clientKey الخاص بـ CapSolver وغلاف مهمة خاصًا بالمزوّد:

{
  "clientKey": "CAPSOLVER_API_KEY",
  "task": {
    "type": "ReCaptchaV3Task",
    "websiteURL": "https://accounts.example.com/login",
    "websiteKey": "PUBLIC_SITE_KEY",
    "pageAction": "login",
    "isEnterprise": true,
    "proxy": "http://user:[email protected]:8080"
  }
}

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

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

المثال هو طلب Enterprise لأنه يترك recaptchaType على قيمته الافتراضية. اختر v3 القياسي صراحةً عندما يستخدمه الموقع المستهدف؛ ولا تحوّل كل أنواع مهام CapSolver إلى Enterprise الافتراضي.

لا يوجد هنا مقابل مباشر بلا وكيل لمهمة ProxyLess في CapSolver: إذ يتطلّب solvethree إدخال وكيل يقدّمه المستدعي. إذا كان تكاملك الحالي لا يدير وكيلاً، فهذا تغيير في التكامل، وليس مجرد إعادة تسمية حقل. ولا تنسخ إعداد وكيل SOCKS إلى الطلب الجديد أيضًا؛ يقبل solvethree عناوين URL لوكلاء HTTP وHTTPS.

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

يسترجع CapSolver النتائج غير المتزامنة عبر getTaskResult باستخدام clientKey وtaskId. أما solvethree فيسترجعها عبر GET /v1/tasks/:id بمصادقة Bearer. حدّث محلّل النتائج إلى جانب استدعاء HTTP؛ فحقول الحالة والخطأ في CapSolver تتبع عقد واجهة مختلفًا.

1. 1.

   تحقّق من استجابة HTTP أولًا

   عالِج استجابات HTTP غير الناجحة قبل قراءة حمولة النجاح. يحتاج خطأ طلب HTTP وفشل مهمة الحل إلى معالجة منفصلة.

2. 2.

   فحص المهمة المُعادة عند الإنشاء

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

3. 3.

   إيقاف الاستعلام المتكرر عند الجاهزية أو الفشل

   في حالة ready، مرّر الحل إلى كود الإرسال. وفي حالة failed، افحص errorCode وerror وأوقف الاستعلام المتكرر عن تلك المهمة. تُردّ رسوم محاولات الحل الفاشلة. لا تُعِد المحاولة عشوائيًا بالمدخلات غير الصالحة نفسها، ولا تفترض أن كل فشل يعني عدم كفاية الرصيد.

أثناء الانتقال المرحلي، احتفظ بوسم يحدّد المزوّد لكل معرّف مهمة. أكمل مهام CapSolver الحالية عبر CapSolver، ووجّه مهام solvethree الجديدة عبر solvethree. وحّد صيغة نتائجها في طبقة التكييف بدلاً من إرسال معرّف مهمة المزوّد القديم إلى واجهة API الجديدة.

استخدم solution.token عند إرسال نتيجة reCAPTCHA إلى الوجهة المقصودة. واحتفظ أيضًا بقيمتَي userAgent وsecChUa المُعادتين، واستخدم الوكيل الناجح للإرسال. إذا كانت طبقة التكييف الحالية تُعيد سلسلة نصية للرمز فقط، فعدّلها لتمرير هذه المعلومات إلى العميل الذي ينفّذ الإرسال.

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

يتضمّن المثال بعد التعديل requestId للاسترداد. أنشئ قيمة لكل مهمة منطقية جديدة واحتفظ بها مع مدخلات الطلب الدقيقة. يجب أن تحتوي على 1–64 محرفًا من حروف ASCII أو الأرقام أو الشرطات السفلية أو الشرطات. تؤدي إعادة استخدامها مع طلب المهمة نفسه إلى إرجاع المهمة الحالية؛ أما استخدامها مع مدخلات مختلفة فيؤدي إلى تعارض.

إذا انتهت مهلة الإنشاء، فاسترجع المهمة إن كان لديك معرّفها، أو أعد إرسال المتن نفسه بقيمة requestId نفسها. فقدان الاستجابة لا يثبت فشل الإنشاء. لا تُنشئ معرّفًا جديدًا لمجرد أن العميل توقف عن الانتظار.

راعِ في مهلة العميل فترة انتظار إنشاء reCAPTCHA الافتراضية التي تصل إلى 15 ثانية، إضافةً إلى التأخير الإضافي للشبكة. تُعيد طلبات الاستعلام المتكرر عبر GET النتيجة دون انتظار افتراضيًا، وتقبل waitMs بقيمة تصل إلى 15000. ضع waitMs في استعلام عنوان URL، وليس في JSON الخاص بالمهمة، وراعِ فترة الانتظار هذه في مهلة الاستعلام المتكرر أيضًا.