קריאה ל-API לפתרון CAPTCHA מתוך n8n

1. 1.

   הפעלת פרופיל האתר

   הגדירו את שם המארח של היעד במסוף של solvethree וודאו שהפרופיל שלו פעיל בסביבת העבודה שלכם. שליחת שם מארח ופעולה במשימה אינה יוצרת את הפרופיל.

2. 2.

   יצירת פרטי אימות מסוג Header Auth ב-n8n

   הגדירו אותם לשליחת כותרת Authorization שערכה הוא Bearer ואחריו מפתח ה-API של סביבת העבודה שלכם. שמרו את המפתח בפרטי האימות, ולא ב-JSON של המשימה.

תנו לצומת HTTP Request את השם Create task. צומת התשאול יפנה לשם הזה כדי לשחזר את מזהה המשימה המקורי.

{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "example_login_001"
}

החליפו את site,‏ action ו-proxy בשם המארח, בפעולה ובפרוקסי של הבקשה שלכם. שלחו בדיוק אחד מהשדות proxy או proxyCandidates; הדוגמה הזו משתמשת בפרוקסי אחד. אל תוסיפו type או url. סוג reCAPTCHA המוגדר כברירת מחדל הוא Enterprise v3.

החליפו את requestId שבדוגמה בערך ייחודי לכל משימה לוגית חדשה. שמרו על אותו ערך אם תצטרכו לשחזר את המשימה לאחר חריגה מזמן ההמתנה. הוא מקבל 1–64 תווים: אותיות ASCII, ספרות, קווים תחתונים או מקפים.

waitMs שייך לשאילתת ה-URL, ולא לגוף ה-JSON. הגדירו לבקשת ה-HTTP זמן קצוב העולה על ההמתנה המבוקשת של 15 שניות כדי להביא בחשבון את תקורת הרשת; 30 שניות הן הגדרה התחלתית סבירה, ולא הבטחה לזמן פתרון. פרטי האימות מסוג Header Auth מספקים את האימות, כך שאין צורך לשכפל אותו תחת שליחת כותרות.

טפלו בתגובות HTTP שאינן מציינות הצלחה לפני בדיקת נתוני המשימה. עבור תגובה מוצלחת, חברו צומת IF או Switch ובדקו את {{ $json.status }}.

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

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

1. 1.

   שמירת מועד סיום קבוע

   לפני הפעלת Create task, שמרו בתהליך העבודה מועד סיום לתשאול — למשל, שתי דקות לאחר תחילת היצירה. זו מדיניות העצירה של תהליך העבודה שלכם, ולא מגבלה של API של solvethree. שמרו את מועד הסיום מחוץ לתגובת ה-HTTP כדי שתגובות מאוחרות יותר לא ידרסו אותו.

2. 2.

   בדיקת תנאי לפני כל סבב תשאול

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

3. 3.

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

   הגדירו צומת HTTP Request נוסף עם ההגדרות שלהלן. נתבו את התגובה שלו חזרה דרך אותה הסתעפות לפי סטטוס. לעולם אל תנתבו את ענף התשאול בחזרה אל Create task.

הביטוי למזהה המשימה הוא {{ $('Create task').item.json.id }}. הוא קורא את id מצומת היצירה ששמו צוין, גם כשהפריט האחרון מכיל תגובת תשאול או נתונים אחרים של תהליך העבודה. ודאו ששם הצומת בביטוי תואם לשמו בתהליך העבודה שלכם.

GET מאפשר המתנה של עד 15 שניות. הקצו לבקשת HTTP זו אותו מרווח זמן קצוב כמו לבקשת היצירה. מועד הסיום מונע ניסיונות תשאול חדשים; בקשה שכבר פועלת יכולה להסתיים אחריו.

בקשת ה-GET המקבילה מחוץ ל-n8n היא:

curl --fail-with-body --max-time 30 \
  "https://api.solvethree.com/v1/tasks/$TASK_ID?waitMs=15000" \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY"

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

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