קריאה ל-API של CAPTCHA מתוך Cloudflare Workers

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

• SOLVETHREE_API_KEY: מפתח ה־API של סביבת העבודה שלכם, השמור כסוד של Worker.
• INTEGRATION_KEY: סוד נפרד שהגורם הקורא ביישום שלכם חייב לשלוח ב־x-integration-key.
• SOLVETHREE_PROXY: כתובת ה־URL של הפרוקסי המשמש לפתרון. שמרו אותה כסוד אם היא מכילה פרטי הזדהות.
• CAPTCHA_SITE: שם המארח של היעד, ולא כתובת URL מלאה.

הדוגמה מקבעת את הפעולה ל־login ומספקת פרוקסי אחד. שנו את הקלטים האלה בפריסה כך שיתאימו לאינטגרציה שלכם; אל תקבלו קלטי יעד שרירותיים מגורמים קוראים. כאשר recaptchaType מושמט, ברירת המחדל של ה־API היא reCAPTCHA Enterprise v3.

השתמשו במפתח האינטגרציה בין גורם קורא מהימן ביישום לבין ה־Worker, ולא בקוד דפדפן שמופץ לציבור. זהו אמצעי הזדהות משותף, ולא הרשאה למשימות ברמת המשתמש.

export default {
  async fetch(request, env) {
    if (!env.INTEGRATION_KEY || request.headers.get('x-integration-key') !== env.INTEGRATION_KEY) {
      return new Response('Unauthorized', { status: 401 });
    }
    const url = new URL(request.url);
    const headers = { Authorization: `Bearer ${env.SOLVETHREE_API_KEY}`, 'Content-Type': 'application/json' };
    let response;
    if (request.method === 'POST') {
      const requestId = request.headers.get('x-request-id');
      if (!requestId || !/^[A-Za-z0-9_-]{1,64}$/.test(requestId)) return new Response('Provide X-Request-ID', { status: 400 });
      response = await fetch('https://api.solvethree.com/v1/tasks?waitMs=0', {
        method: 'POST', headers, redirect: 'error', signal: AbortSignal.timeout(20000),
        body: JSON.stringify({ site: env.CAPTCHA_SITE, action: 'login', proxy: env.SOLVETHREE_PROXY, requestId }),
      });
    } else if (request.method === 'GET') {
      const id = url.searchParams.get('id');
      if (!id || !/^[A-Za-z0-9_-]{1,128}$/.test(id)) return new Response('Provide a valid id', { status: 400 });
      response = await fetch(`https://api.solvethree.com/v1/tasks/${encodeURIComponent(id)}?waitMs=15000`, {
        headers, redirect: 'error', signal: AbortSignal.timeout(25000),
      });
    } else return new Response('Use POST or GET', { status: 405 });
    if (!response.ok) return Response.json({ error: 'Solver API request failed', status: response.status }, { status: response.status });
    return Response.json(await response.json(), { headers: { 'Cache-Control': 'no-store' } });
  },
};
// Store keys in Worker secret bindings. The task proxy field does not add a
// generic HTTP proxy option to Workers fetch; another client must submit through it.

1. 1.

   יצירת משימה

   שלחו בקשת POST ל־Worker עם x-integration-key ו־x-request-id. בחרו מזהה בקשה שמכיל 1–64 אותיות ASCII, ספרות, קווים תחתונים או מקפים. ה־Worker בונה את גוף המשימה מהיעד ומהפרוקסי שהוגדרו בו; הוא אינו משתמש בגוף שסיפק הגורם הקורא.

2. 2.

   שמירת מזהה המשימה

   ה־Worker מחזיר את תגובת ה־JSON של שירות הפתרון. שמרו את מזהה המשימה שהוחזר ואת מזהה הבקשה ששימש ליצירתה.

3. 3.

   אחזור התוצאה

   שלחו בקשת GET ל־Worker עם מזהה המשימה בפרמטר השאילתה id ואותה כותרת של מפתח האינטגרציה. פונקציית הטיפול מאמתת את תחביר המזהה ומאחזרת את המשימה מ־solvethree.

שתי הבקשות לשירות המקור מאומתות באמצעות מפתח סביבת העבודה. פונקציית הטיפול מעבירה קודי מצב HTTP שאינם מציינים הצלחה עם גוף שגיאה כללי, ומסמנת תגובות JSON מוצלחות ב־Cache-Control: no-store. היא אינה בודקת בעלות על משימות מעבר למפתח האינטגרציה המשותף; הוסיפו בדיקת הרשאה זו לפני שתאפשרו אחזור למשתמשים נפרדים.

היצירה משתמשת ב־waitMs=0 עם זמן המתנה מרבי של 20 שניות ל־fetch. האחזור משתמש ב־waitMs=15000 עם זמן המתנה מרבי של 25 שניות ל־fetch. מגבלות אלה חלות על קריאות HTTP בודדות, ולא על כל משך חיי המשימה.

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

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

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

שגיאת HTTP ומשימה במצב failed הן כשלים שונים. פונקציית הטיפול בודקת תחילה את מצב ה־HTTP; הגורם הקורא עדיין חייב לבדוק את מצב המשימה בתגובה מוצלחת. לצורך אבחון, עיינו בשגיאות API של CAPTCHA.

דוגמת ה־Worker קוראת רק ל־solvethree. השדה proxy במשימה מציין לשירות הפתרון באיזה פרוקסי להשתמש; הוא אינו משנה את ניתוב הרשת של ה־Worker. ל־fetch ב־Workers אין אפשרות כללית להגדרת כתובת URL של פרוקסי.

שלחו את הפתרון המוכן ללקוח שיכול לשלוח אותו ליעד המיועד דרך אותו פרוקסי. השתמשו בערכי userAgent ו־secChUa שהוחזרו בפתרון, במקום בכותרות דפדפן שאינן קשורות. משימה מוכנה פירושה ש־solvethree יצר פתרון; קבלתו תלויה בבקשה שנשלחת ליעד לאחר מכן.