העברת אינטגרציית reCAPTCHA מ-CapSolver ל-solvethree
שינוי שם המארח של ה-API אינו מספיק. החליפו את clientKey ואת task המקונן של CapSolver באימות Bearer ובגוף בקשה שטוח, ואז עדכנו את אופן האחזור והשליחה של התוצאה.
בדף הזה
וידוא שהמשימה נתמכת והגדרת האתר
ברירת המחדל של solvethree היא reCAPTCHA v3 Enterprise, והוא מקבל גם v3 רגיל. המוצרים הציבוריים האחרים שלו הם Kasada ו-Ticketmaster TMPT. הוא אינו תומך ב-reCAPTCHA v2, ב-hCaptcha, ב-Turnstile או בפתרון באמצעות תוסף לדפדפן, ולכן אינו תחליף אוניברסלי לכל אינטגרציה של CapSolver.
לפני שליחת משימת reCAPTCHA, הגדירו את אתר היעד במסוף וודאו שפרופיל פעיל זמין לסביבת העבודה שלכם. שליחת שם מארח ופעולה אינה יוצרת את הפרופיל הזה. אל תסירו את השדה websiteKey של CapSolver ותניחו ששאר הבקשה מספיקה.
החלפת האימות וגוף הבקשה
הבקשה המקורית משתמשת ב-clientKey של CapSolver ובמעטפת משימה ייעודית לספק:
{
"clientKey": "CAPSOLVER_API_KEY",
"task": {
"type": "ReCaptchaV3Task",
"websiteURL": "https://accounts.example.com/login",
"websiteKey": "PUBLIC_SITE_KEY",
"pageAction": "login",
"isEnterprise": true,
"proxy": "http://user:[email protected]:8080"
}
}עבור solvethree, שלחו את הגוף השטוח שלהלן אל POST https://api.solvethree.com/v1/tasks. הגדירו את הכותרת Authorization לערך Bearer ואחריו מפתח ה-API של סביבת העבודה שלכם. שמרו את המפתח הזה בשרת; אל תעבירו את clientKey לגוף ה-JSON החדש.
{
"site": "accounts.example.com",
"action": "login",
"proxy": "http://user:[email protected]:8080",
"requestId": "example_login_001"
}| קלט של CapSolver | מיפוי ל-solvethree |
|---|---|
clientKey | העבירו את האימות לכותרת Bearer באמצעות מפתח API של סביבת עבודה ב-solvethree. |
task | הסירו את המעטפת; שדות המשימה שייכים לרמה העליונה. |
task.type ו-isEnterprise | אל תשלחו אף אחד מהשדות. ברירת המחדל של recaptchaType היא enterprise-v3; הגדירו אותו ל-v3 עבור v3 רגיל. |
websiteURL | השתמשו רק בשם המארח בתוך site: accounts.example.com, ללא הסכמה או הנתיב /login. אל תשלחו שדה url. |
websiteKey | השמיטו אותו מגוף המשימה הציבורי. לאתר חייב כבר להיות פרופיל פעיל הזמין לסביבת העבודה. |
pageAction | שלחו את הפעולה הרצויה בתור action; הדוגמה משאירה את login. |
proxy | ספקו כתובת URL של פרוקסי HTTP או HTTPS. נדרש בדיוק אחד מהשדות proxy או proxyCandidates. |
הדוגמה היא בקשת Enterprise משום שהיא משאירה את recaptchaType בערך ברירת המחדל שלו. בחרו במפורש ב-v3 רגיל כאשר זה הסוג שבו משתמש היעד שלכם; אל תמפו כל סוג משימה של CapSolver לברירת המחדל Enterprise.
טיפול בהנחות של ProxyLess לפני המעבר
למשימת ProxyLess של CapSolver אין כאן מקבילה ישירה ללא פרוקסי: solvethree דורש קלט פרוקסי שמספק הקורא. אם האינטגרציה הנוכחית שלכם אינה מנהלת פרוקסי, זהו שינוי באינטגרציה ולא שינוי שם של שדה. אל תעתיקו גם הגדרת פרוקסי SOCKS לבקשה החדשה; solvethree מקבל כתובות URL של פרוקסי HTTP ו-HTTPS.
התחילו עם פרוקסי יחיד כדי שהנתיב המשמש לפתרון ולשליחה יהיה חד-משמעי. אם אתם משתמשים במקום זאת ב-proxyCandidates, ספקו לכל היותר שתים עשרה כתובות URL שונות של פרוקסי HTTP או HTTPS, ללא נתיבים, שאילתות או מקטעים. המועמדים מאפשרים לשירות לנסות נקודות יציאה חלופיות; הם אינם מבטיחים שפרוקסי או יעד יעבדו.
החלפת getTaskResult במחזור החיים של המשימה
CapSolver מאחזר תוצאות אסינכרוניות דרך getTaskResult עם clientKey ו-taskId. solvethree מאחזר אותן דרך GET /v1/tasks/:id עם אימות Bearer. עדכנו את מנתח התוצאות וגם את קריאת ה-HTTP; שדות הסטטוס והשגיאה של CapSolver שייכים לחוזה ממשק אחר.
- 1.
בדיקת תגובת ה־HTTP תחילה
טפלו בתגובות HTTP שאינן מציינות הצלחה לפני קריאת נתוני תגובה מוצלחת. שגיאה בבקשת HTTP ומשימת פתרון שנכשלה דורשות טיפול נפרד.
- 2.
בדיקת המשימה שהוחזרה מהיצירה
יצירת reCAPTCHA ממתינה עד 15 שניות כברירת מחדל, כך שהתגובה עשויה כבר להיות במצב סופי. רק
readyמכיל פתרון שמיש. אם המשימה היאpendingאוsolving, אחזרו אותה באמצעות מזהה המשימה של solvethree שהוחזר. - 3.
עצירת התשאול במצב ready או failed
במצב
ready, העבירו את הפתרון לקוד השליחה שלכם. במצבfailed, בדקו אתerrorCodeואתerrorוהפסיקו לתשאל את המשימה הזו. על פתרונות שנכשלו ניתן החזר. אל תנסו שוב באופן עיוור עם אותם נתוני קלט לא תקינים ואל תניחו שכל כישלון מעיד על יתרה לא מספקת.
במהלך מעבר הדרגתי, סמנו כל מזהה משימה בספק שלו. השלימו משימות קיימות של CapSolver דרך CapSolver ונתבו משימות חדשות של solvethree דרך solvethree. נרמלו את התוצאות שלהן במתאם שלכם במקום לשלוח מזהה משימה של ספק ישן ל-API החדש.
החזרת יותר ממחרוזת טוקן מהמתאם שלכם
השתמשו ב-solution.token בעת שליחת תוצאת reCAPTCHA ליעד המיועד. שמרו גם את userAgent ואת secChUa שהוחזרו, והשתמשו בפרוקסי שהצליח לצורך השליחה. אם המתאם הקיים שלכם מחזיר רק מחרוזת טוקן, שנו אותו כך שיעביר את המידע הזה עד ללקוח השולח.
אם טוקן מוכן נדחה, בדקו את בקשת האפליקציה היוצאת לפני שתשלמו על פתרון נוסף. ודאו שהיא מכילה את הטוקן החדש — ולא מזהה משימה או טוקן ישן — ושהשליחה משתמשת בזהות הדפדפן שהוחזרה, בפרוקסי שהצליח ובכתובת ה-URL של היעד המיועד. משימה במצב ready פירושה שנוצר פתרון, ולא שהיעד קיבל את הבקשה ששלחתם לאחר מכן.
התאוששות מבקשות יצירה שחרגו מזמן ההמתנה ללא עבודה כפולה
הדוגמה שלאחר המעבר כוללת requestId לצורך התאוששות. צרו אחד לכל משימה לוגית חדשה ושמרו אותו עם נתוני הקלט המדויקים של הבקשה. עליו להכיל 1–64 תווים: אותיות ASCII, ספרות, קווים תחתונים או מקפים. שימוש חוזר בו עם אותה בקשת משימה מחזיר את המשימה הקיימת; שימוש בו עם נתוני קלט שונים גורם להתנגשות.
אם היצירה חורגת מזמן ההמתנה, אחזרו את המשימה אם המזהה שלה בידיכם, או שלחו מחדש את אותו גוף בקשה עם אותו requestId. תגובה שאבדה אינה מוכיחה שהיצירה נכשלה. אל תיצרו מזהה חדש רק מפני שהלקוח שלכם הפסיק להמתין.
הביאו בחשבון בזמן הקצוב של הלקוח את המתנת היצירה של reCAPTCHA, שברירת המחדל שלה היא עד 15 שניות, בתוספת תקורת רשת. תשאול GET חוזר ללא המתנה כברירת מחדל ומקבל waitMs עד 15000. הציבו את waitMs בשאילתת ה-URL, ולא ב-JSON של המשימה, והביאו את ההמתנה הזו בחשבון גם בזמן הקצוב לתשאול.
מקורות ותיעוד API
הפעלת המשימה הראשונה שלך.
התחילו עם $5 בקרדיט לסביבת העבודה.