שימוש ב-APIRequestContext של Playwright עם פתרון CAPTCHA

1. 1.

   התקנת התלויות

   השתמשו ב-Node.js 22+ והתקינו את החבילה playwright. התקינו את ה-SDK הרשמי ל-JavaScript מארכיון ה-tar של solvethree בגרסה 0.1.0:‏ solvethree-sdk-0.1.0.tgz, שנמצא תחת /downloads/ באתר solvethree.com. מייבאים אותו בשם @solvethree/sdk; אל תניחו שגרסה זמינה במאגר החבילות.

2. 2.

   הגדרת משתני הסביבה

   ספקו לתהליך Node.js את SOLVETHREE_API_KEY,‏ SOLVETHREE_PROXY ו-TARGET_URL. שמרו את מפתח ה-API של סביבת העבודה בצד השרת. TARGET_URL חייב להיות נקודת הקצה בפועל של האפליקציה לבקשות POST, ולא רק הדף שמציג את ה-CAPTCHA. השתמשו בכתובת URL של פרוקסי HTTP או HTTPS ללא נתיב, שאילתה או מקטע.

3. 3.

   ודאו שפרופיל האתר והפעולה נכונים

   לשם המארח של היעד נדרש פרופיל פעיל שזמין לסביבת העבודה שלכם. הגדירו אותו בקונסולה לפני הפתרון; העברת שם מארח לא יוצרת פרופיל. הדוגמה משתמשת בפעולה login; שנו אותה אם היעד מצפה לפעולה אחרת. ברירת המחדל של הבקשה היא reCAPTCHA Enterprise v3.

לפני הרצת הדוגמה, הכינו את שדות הטופס הנדרשים באפליקציה ואת הדרוש להפעלת סשן. הדוגמה שולחת רק את שדה התשובה של ה-CAPTCHA. אם שם המארח עדיין לא מוגדר, עיינו בהגדרת פרופיל אתר.

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.

כדאי לנסות: טפלו בתגובה שאינה מציינת הצלחה לפני שתתייחסו לגוף שלה כאל נתוני הצלחה. תקנו את הבקשה לאפליקציה או את שגיאת השרת שדווחה, במקום להניח שהטוקן גרם לה.