اتصال API ووكيل CAPTCHA مختلفان

Application server
  -> HTTPS api.solvethree.com/v1/tasks
     Authorization: Bearer <workspace API key>
     JSON: { "site": "accounts.example.com", "action": "login", "proxy": "http://USER:PASS@PROXY:PORT" }

solvethree solves through the proxy supplied in that JSON.

Application or browser
  -> the SAME successful proxy and pinned exit
  -> intended target, with the returned token/headers/cookie and browser identity

The API key belongs on the API request, never the target request.
Putting a proxy URL in task JSON does not configure the application's HTTP client.

يرسل خادمك طلب HTTPS مصادقًا عليه إلى واجهة API الخاصة بـ solvethree. يُرسل عنوان URL للوكيل داخل جسم JSON؛ ثم تستخدم solvethree ذلك الوكيل للحل. بعد ذلك، يرسل تطبيقك أو متصفحك طلبًا منفصلًا إلى الجهة المستهدفة. لا يضبط حقل المهمة ولا استدعاء حزمة SDK ذلك الاتصال الأخير تلقائيًا.

استبدل اسم المضيف والإجراء وبيانات اعتماد الوكيل في المثال بقيمك الخاصة. يحتاج الموقع إلى ملف تعريف نشط متاح لمساحة عملك؛ وإرسال اسم مضيفه لا ينشئ ملفًا. راجع إعداد ملف تعريف الموقع.

احتفظ بمفتاح API لمساحة العمل على خادمك. أرسل ترويسة تفويض Bearer الخاصة به إلى مضيف API فقط، بما في ذلك عند استرجاع حالة المهمة. لا تنسخ تلك الترويسة إلى الطلب الموجّه للجهة المستهدفة ولا تستخدمها للمصادقة لدى الوكيل.

اضبط عميل HTTP أو المتصفح الذي يرسل الحل بشكل منفصل. استخدم الوكيل الناجح مع هوية المتصفح المُعادة في userAgent وsecChUa. لا تجمع الحل مع هوية متصفح أو وكيل أو عنوان URL مستهدف لا يرتبط به.

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

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

تعني حالة المهمة ready أن الحل متاح. أما القبول فهو نتيجة منفصلة: افحص استجابة الجهة المستهدفة للطلب الذي يحمل ذلك الحل.

إذا كان عميل HTTP يقرأ HTTP_PROXY أو إعدادات الوكيل الأخرى في البيئة، فتحقق مما إذا كانت هذه الإعدادات توجّه أيضًا الطلبات إلى api.solvethree.com. فقد يؤدي ذلك إلى تمرير اتصال API عبر وكيل قصدت استخدامه لحركة البيانات الموجّهة للجهة المستهدفة فقط. افحص إعدادات النقل الفعلية للعميل بدلًا من افتراض مطابقتها لبيانات JSON الخاصة بالمهمة.

اضبط نقل API والنقل إلى الجهة المستهدفة بشكل منفصل. إعداد الوكيل في البيئة ليس بديلًا عن حقل المهمة المطلوب: لا يزال طلب reCAPTCHA يحتاج إلى واحد فقط من proxy أو proxyCandidates.

يفشل طلب API قبل أن تتلقى مهمة.

تحقق من استجابة HTTP والمسار الذي استخدمه عميل API، بما في ذلك أي إعدادات وكيل في البيئة.

جرّب هذا: تعامل مع خطأ HTTP قبل قراءة بيانات استجابة النجاح. صحّح توجيه API غير المقصود بدلًا من تغيير وكيل المهمة دون تشخيص.

تتلقى HTTP 407.

حدّد الاتصال الذي واجه فشل المصادقة لدى الوكيل: اتصال API أم اتصال يستخدم وكيل المهمة.

جرّب هذا: صحّح بيانات اعتماد ذلك الوكيل. استخدم الترميز المئوي للأحرف المحجوزة داخل جزأي اسم المستخدم وكلمة المرور، لا لعنوان URL بأكمله.

تنتهي مهلة إنشاء المهمة.

انتهاء المهلة لا يثبت أن واجهة API فشلت في إنشاء المهمة.

جرّب هذا: استرجع المهمة إذا كان لديك معرّفها. إذا كنت قد أرسلت requestId، فاستعدها بتكرار طلب المهمة نفسه بذلك المعرّف قبل إنشاء مهمة منطقية جديدة.

تصل المهمة إلى الحالة failed.

اقرأ errorCode وerror الخاصين بها؛ فهذا يختلف عن خطأ نقل HTTP.

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