استخدام APIRequestContext في Playwright مع حل CAPTCHA

بقلم solvethreeمدة القراءة: 4 دقيقة

استخدم request.newContext() عندما تعرف مسبقًا نقطة نهاية POST وحقول النموذج الخاصة بالتطبيق. فهو ينشئ عميل HTTP دون تشغيل Chromium. لا تحتاج إلى التفاعل مع حقول المتصفح لمجرد إرسال رمز solvethree.

إذا كان التطبيق يحتاج إلى ملفات تعريف الارتباط أو بيانات CSRF أو حقول نموذج أخرى، فوفّرها أيضًا. تحل حزمة SDK اختبار CAPTCHA؛ لكنها لا تعيد بناء تدفق تسجيل الدخول إلى التطبيق.

في هذه الصفحة

جهّز الاعتماديات والطلب المستهدف

  1. 1.

    تثبيت الاعتماديات

    استخدم Node.js 22+ وثبّت حزمة playwright. ثبّت حزمة JavaScript SDK الرسمية من أرشيف tar للإصدار 0.1.0 من solvethree: solvethree-sdk-0.1.0.tgz، الموجود ضمن /downloads/ على solvethree.com. تُستورد الحزمة باسم @solvethree/sdk؛ لا تفترض وجود إصدار متاح في سجل الحزم.

  2. 2.

    تعيين متغيرات البيئة

    مرّر SOLVETHREE_API_KEY وSOLVETHREE_PROXY وTARGET_URL إلى عملية Node.js. احتفظ بمفتاح API لمساحة العمل على جانب الخادم. يجب أن يكون TARGET_URL نقطة نهاية POST الفعلية للتطبيق، وليس مجرد الصفحة التي تعرض اختبار CAPTCHA. استخدم عنوان URL لبروكسي HTTP أو HTTPS دون مسار أو استعلام أو جزء محدد.

  3. 3.

    تحقّق من ملف تعريف الموقع والإجراء

    يحتاج اسم المضيف المستهدف إلى ملف تعريف نشط متاح لمساحة عملك. أعدّه في لوحة التحكم قبل الحل؛ فتمرير اسم مضيف لا ينشئ ملف تعريف. يستخدم المثال الإجراء login؛ غيّره إذا كانت الوجهة المستهدفة تتوقع إجراءً آخر. يستخدم الطلب reCAPTCHA Enterprise v3 افتراضيًا.

جهّز حقول النموذج المطلوبة للتطبيق ومتطلبات الجلسة قبل تشغيل المثال. فهو يرسل حقل استجابة CAPTCHA فقط. راجع إعداد ملف تعريف الموقع إذا لم يكن اسم المضيف مُعدًّا بعد.

حلّ الاختبار، ثم أرسل عبر البروكسي نفسه

Playwright APIRequestContext · لا حاجة إلى متصفح
import { request } from 'playwright';
import { Solvethree } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
const target = new URL(process.env.TARGET_URL);
const proxy = new URL(process.env.SOLVETHREE_PROXY);
const result = await client.solve({ site: target.hostname, action: 'login', proxy: process.env.SOLVETHREE_PROXY });
const proxyConfig = { server: `${proxy.protocol}//${proxy.host}`, username: decodeURIComponent(proxy.username), password: decodeURIComponent(proxy.password) };

const targetClient = await request.newContext({
  proxy: proxyConfig, timeout: 30000,
  extraHTTPHeaders: { 'User-Agent': result.solution.userAgent, 'sec-ch-ua': result.solution.secChUa },
  // storageState: 'your-application-session.json', // only if your flow needs it
});
try {
  const response = await targetClient.post(target.href, {
    form: { 'g-recaptcha-response': result.solution.token }, maxRedirects: 0,
  });
  console.log('Application HTTP status:', response.status());
  // Inspect the response and supply the application's actual fields/CSRF/session.
} finally { await targetClient.dispose(); }

ينشئ client.solve() المهمة مرة واحدة ويستطلع حالتها حتى تصبح جاهزة أو يطرح استثناءً. يستخدم المثال بروكسي واحدًا للحل والإرسال معًا. وبالنسبة إلى Playwright، يفصل عنوان خادم البروكسي عن بيانات اعتماده ويفك ترميز اسم المستخدم وكلمة المرور.

يطبّق سياق الطلب solution.userAgent وsolution.secChUa كترويسات. يرسل النموذج solution.token في g-recaptcha-response، وليس معرّف المهمة. استخدم البروكسي والهوية المُعادة معًا؛ ولا تستبدلهما بترويسات متصفح غير مرتبطة بهما أو ترسل الرمز إلى وجهة مستهدفة مختلفة.

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

يحتفظ APIRequestContext بمخزن خاص لملفات تعريف الارتباط، لذا تحتفظ الطلبات المُرسلة عبر السياق نفسه بملفات تعريف الارتباط التي يتلقاها. ولا يشاركها تلقائيًا مع سياق متصفح غير مرتبط به. أبقِ طلبات الجلسة التمهيدية وطلب POST النهائي في السياق نفسه عندما تحتاج إلى مشاركة ملفات تعريف الارتباط. تتخلص كتلة finally من السياق عند انتهاء الإرسال.

تحقّق من استجابة التطبيق قبل الحل مجددًا

يسجّل المثال حالة HTTP للتطبيق؛ لكنه لا يثبت نجاح تسجيل الدخول. عند ضبط maxRedirects على صفر، ترى الاستجابة الأولية بدلًا من اتباع إعادة التوجيه. افحص متنها وترويساتها وملفات تعريف الارتباط وقارنها باستجابة النجاح المتوقعة من التطبيق. قد لا تكفي إعادة التوجيه أو حالة HTTP 200 وحدها لمعرفة ما إذا كانت العملية قد نجحت.

المهمة جاهزة، لكن التطبيق يرفض طلب POST.

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

جرّب هذا: صحّح بيانات الطلب الناقصة أو غير المتطابقة قبل الدفع مقابل حل آخر. توفّر المهمة الجاهزة حلًا قابلًا للاستخدام، لا ضمانًا لقبوله لدى التطبيق المستهدف.

تنتهي محاولة الحل بمهمة فاشلة.

اقرأ errorCode وerror؛ ولا تعتبر كل فشل مشكلة في الرصيد.

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

تنتهي مهلة إنشاء المهمة أو ينقطع الاتصال.

تحقّق مما إذا كان لديك معرّف مهمة أو كنت قد استخدمت requestId. انتهاء مهلة الاتصال لا يثبت فشل الإنشاء.

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

يعيد طلب التطبيق خطأ HTTP.

افحص استجابة الوجهة المستهدفة بشكل منفصل عن نتيجة مهمة solvethree.

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

شغّل مهمتك الأولى.

ابدأ برصيد قدره $5 في مساحة العمل.

إنشاء مساحة عمل
استخدام APIRequestContext في Playwright مع حل CAPTCHA · solvethree