استخدام API مهام CAPTCHA في Make

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

1. 1.

   اضبط مصادقة HTTP v4

   اختر نوع المصادقة API key وأنشئ سلسلة مفاتيح لبيانات الاعتماد. اضبط المفتاح على Bearer متبوعًا بمسافة ومفتاح API لمساحة عملك، والموضع على In the header، واسم المعامل على Authorization. اقصر أصول الخدمة المسموح بها على https://api.solvethree.com. احتفظ بالمفتاح في سلسلة المفاتيح بدلًا من تمريره عبر بيانات السيناريو.

2. 2.

   أدخل إعدادات الطلب

   استخدم الطريقة وعنوان URL ومعامل الاستعلام والترويسة وجسم JSON الموضحة أدناه. أدخل كلًا منها في حقل الوحدة المقابل له. وحدها محتويات body توضع في محتوى طلب JSON؛ المثال الكامل إعدادات توضيحية، وليس مخطط Make قابلًا للاستيراد.

{
  "method": "POST",
  "url": "https://api.solvethree.com/v1/tasks",
  "query": {
    "waitMs": "0"
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "site": "accounts.example.com",
    "action": "login",
    "proxy": "http://USER:PASSWORD@PROXY:PORT",
    "requestId": "one-stable-id-for-this-logical-job"
  },
  "authentication": {
    "type": "API key",
    "Key": "Bearer YOUR_PRIVATE_WORKSPACE_KEY",
    "API key placement": "In the header",
    "API key parameter name": "Authorization",
    "Allowed service origins": [
      "https://api.solvethree.com"
    ]
  }
}

• استبدل site باسم المضيف المُعدّ، وليس بعنوان URL كامل. اضبط action على الإجراء المستخدم في التدفق المستهدف.
• استبدل proxy بعنوان URL لوكيلك. يتطلب الطلب واحدًا فقط من proxy أو proxyCandidates؛ يستخدم المثال وكيلًا واحدًا.
• امنح كل عملية منطقية جديدة requestId خاصًا بها، واحتفظ به للاستعادة. قيمة المثال عنصر نائب، وليست معرّفًا لإعادة استخدامه في عمليات غير مرتبطة.
• لا تضف type أو url إلى طلب reCAPTCHA هذا. عند حذف recaptchaType، تكون قيمته الافتراضية enterprise-v3.

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

عالج استجابات HTTP غير الناجحة قبل التوجيه بحسب حالة المهمة. خطأ HTTP ليس مماثلًا لمهمة حالتها failed؛ لا تتعامل مع استجابة غير قابلة للقراءة أو غير ناجحة بوصفها نتيجة pending أخرى.

بعد نجاح GET، أضف موجّهًا بمرشحات صريحة على status المُعاد. لا ترسل كل استجابة HTTP ناجحة إلى مسار الحل.

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

ينفّذ التصميم البسيط المحدود طلب GET واحدًا في كل دورة استطلاع. احفظ العمل غير المكتمل في مكان يمكن للدورة التالية قراءته؛ لا تعتمد على معرّف مهمة لا يوجد إلا في التنفيذ الحالي.

1. 1.

   اختر مسار الدخول

   إذا كان للعملية معرّف مهمة بالفعل، فانتقل مباشرة إلى GET. وحدها العملية الجديدة التي ليس لها مهمة موجودة يجب أن تدخل مسار الإنشاء.

2. 2.

   أنهِ دورات التشغيل غير المكتملة

   في حالتي pending أو solving، احتفظ بمعرّف المهمة وأنهِ دورة التشغيل. عند الاستئناف، استرجع المعرّف نفسه. علّم المهام التي وصلت إلى حالة نهائية بأنها مغلقة كي لا تعالج دورات الاستطلاع اللاحقة نتائجها مجددًا.

3. 3.

   ضع حدًا لأي مكرّر

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

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

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