טיפול בטוח בתוצאות משימות CAPTCHA ב-TypeScript

השתמשו בטיפוסים המיוצאים של ה-SDK: ‏TaskRequest לקלט ו-TaskResult לתגובות. צמצום הטיפוס לפי הסטטוס מאפשר ל-TypeScript להבחין בין עבודה שטרם הסתיימה, כשל ומוכנות, בלי any או המרת טיפוס שרק אומרת למהדר לסמוך עליכם.

import { Solvethree, type TaskRequest, type TaskResult } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY! });
const input: TaskRequest = { site: 'accounts.example.com', action: 'login', proxy: process.env.SOLVETHREE_PROXY! };
function inspect(result: TaskResult): void {
  switch (result.status) {
    case 'pending':
    case 'solving':
      console.log('Retrieve this task again:', result.id);
      return;
    case 'failed':
      console.error('Failed task:', result.id, result.errorCode);
      return;
    case 'ready':
      // Solution fields depend on the requested product; check optional fields.
      if (!result.solution.token || !result.solution.userAgent || !result.solution.secChUa) {
        throw new Error('Expected a complete reCAPTCHA solution');
      }
      console.log('Ready task:', result.id);
      // Submit token privately with its browser identity and original proxy.
      return;
  }
}
inspect(await client.createTask(input, { waitMs: 0 }));
// Save the returned ID and call getTask while pending/solving with a deadline.

הדוגמה יוצרת משימה אחת ובודקת את התגובה המיידית. pending ו-solving מציינים שיש לאחזר אותה שוב; failed עוצר את העיבוד; ready מוביל לבדיקות הפתרון. אם מחלצים את הענף של ready לפונקציית עזר, יש להשתמש בטיפוס המיוצא ReadyTask עבור הפרמטר שלה. כך מצמצמים את הסטטוס האפשרי, אבל לא הופכים כל שדה פתרון ייעודי למוצר לשדה חובה.

הבדיקות מוודאות שקיימים טוקן ושני שדות זהות הדפדפן, כי הקלט הזה מבקש reCAPTCHA. הן אינן מוכיחות שהיעד יקבל את הטוקן. הדוגמה נמנעת במכוון מהדפסת הטוקן.

• יש להשתמש ב-Node.js 22+ ובהתקנה הרשמית של ה-SDK מקובץ tarball, כפי שמתועד בתיעוד ה-API; אין להניח שקיימת גרסה ברישום npm.
• יש להגדיר את SOLVETHREE_API_KEY ואת SOLVETHREE_PROXY בסביבת השרת. הצהרות ! אינן בודקות בזמן ריצה אם חסרים משתני סביבה.
• יש להחליף את accounts.example.com ואת login בשם המארח ובפעולה הרצויים. לאתר כבר חייב להיות פרופיל פעיל בסביבת העבודה; ראו הגדרת פרופיל אתר.

הדוגמה משאירה את התשאול לקוד הקורא. יש להשאיר את היצירה מחוץ ללולאה הזו: קריאה נוספת ל-createTask אינה הדרך לבדוק אם המשימה הראשונה הסתיימה.

1. 1.

   שמרו את המזהה מתוצאת היצירה

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

2. 2.

   אחזרו את אותה משימה

   יש לקרוא ל-getTask עם המזהה השמור כל עוד הסטטוס הוא pending או solving, בכפוף למועד סיום מקומי. לפני עיבוד כל תגובה, יש לבדוק שהמזהה שלה תואם למזהה השמור. מזהה תואם מבהיר באיזו משימה מטפלים, לא אם היא הצליחה.

3. 3.

   עצרו בתוצאה סופית

   בסטטוס ready, יש לאמת את השדות הנדרשים למוצר שהתבקש. בסטטוס failed, יש לבדוק גם את errorCode וגם את error, ואז להפסיק לתשאל את המשימה הזו. יש לטפל בנפרד בשגיאות בקשה: בקשת אחזור שלא הצליחה אינה כשלעצמה כשל סופי של המשימה.

אם הזמן הקצוב ליצירה מסתיים לפני שהתקבל מזהה, אין להניח שלא נוצרה משימה. אם סיפקתם requestId, שליחה חוזרת של הבקשה הזהה עם אותו ערך משחזרת את המשימה הקיימת. שימוש חוזר בו עם קלט ששונה יוצר התנגשות; יצירת ערך חדש אינה משחזרת את המשימה המקורית.

יש לבחור את המטפל לפי הבקשה המקורית, ואז לבדוק את שדות הפתרון הצפויים. עצם קיומו של טוקן אינו מאפשר להבחין בין תגובת reCAPTCHA לבין ערך של עוגיית TMPT.

Kasada במתכונת עצמאית תומך כרגע ביעדי HTTPS ב-www.ticketmaster.com, ולא באתרים שרירותיים. מטפל הכותרות שלו אינו אינטגרציית Kasada אוניברסלית.

בכל מוצר, יש לשלוח עם userAgent ו-secChUa שהוחזרו ועם הפרוקסי שהצליח. כשמשתמשים במועמדי פרוקסי, יש להשתמש ב-successfulProxy(originalTask, readyResult) במקום להניח שהמועמד הראשון הצליח. ה-SDK אינו מחיל עבורכם את הפתרון על היעד, ו-ready אינו מבטיח שהבקשה הבאה תתקבל.