העברת אינטגרציית reCAPTCHA מ-2Captcha ל-solvethree
זה אינו רק שינוי של נקודת קצה. החליפו את מעטפת clientKey/task בבקשה שטוחה המאומתת באמצעות מפתח Bearer, הגדירו את אתר היעד ב-solvethree וספקו פרוקסי. שמרו את מזהי המשימות הקיימים של 2Captcha בנפרד ממשימות solvethree החדשות.
בדף הזה
בדיקת המשימה שאתם מעבירים
המעבר הזה מתייחס ל-reCAPTCHA v3 Enterprise דרך 2Captcha API v2. הוא אינו מתאר את ה-API הישן in.php/res.php. כמו כן, גרסת ה-API של 2Captcha אינה גרסת ה-CAPTCHA: solvethree אינו תומך ב-reCAPTCHA v2.
הבקשה המקורית משתמשת במעטפת המתועדת ב-createTask של 2Captcha: פרטי אימות מחוץ לאובייקט משימה ייעודי לספק.
{
"clientKey": "TWO_CAPTCHA_API_KEY",
"task": {
"type": "RecaptchaV3TaskProxyless",
"websiteURL": "https://accounts.example.com/login",
"websiteKey": "PUBLIC_SITE_KEY",
"minScore": 0.7,
"pageAction": "login",
"isEnterprise": true
}
}אל תעבירו את האובייקט הזה ל-API החדש ללא שינוי. בפרט, לסוג המשימה ללא פרוקסי ול-minScore אין מקום בבקשת solvethree שלהלן.
הגדרת האתר ולאחר מכן החלפת הבקשה
ראשית, הגדירו את אתר היעד במסוף של solvethree. סביבת העבודה שלכם זקוקה לפרופיל אתר פעיל כדי לפתור בקשות עבור שם המארח הזה. שליחת שם מארח ופעולה אינה יוצרת פרופיל כזה.
צרו משימות חדשות באמצעות POST /v1/tasks בכתובת https://api.solvethree.com, עם Authorization: Bearer ומפתח ה-API של סביבת העבודה שלכם. שמרו את המפתח בשרת. מפרט יצירת המשימות משתמש בגוף JSON שטוח במקום באובייקט task מקונן.
| קלט של 2Captcha API v2 | החלופה ב-solvethree |
|---|---|
| clientKey | מפתח ה-API של סביבת העבודה בכותרת Authorization, ולא בגוף ה-JSON. |
| מעטפת task | הסירו אותה; שלחו את שדות המשימה ברמה העליונה. |
| type: RecaptchaV3TaskProxyless | השמיטו את type. ספקו בדיוק אחד מהשדות proxy או proxyCandidates. |
| websiteURL | השתמשו ב-site עם שם המארח בלבד: accounts.example.com. אל תשלחו url. |
| websiteKey | הגדירו את פרופיל אתר היעד במסוף במקום להעתיק את השדה הזה למשימה. |
| pageAction | השתמשו ב-action עם ערך הפעולה של היעד, למשל login. |
| isEnterprise | השמיטו אותו; ברירת המחדל של recaptchaType היא enterprise-v3. |
| minScore | השמיטו אותו; אל תעתיקו אותו לבקשת solvethree. |
{
"site": "accounts.example.com",
"action": "login",
"proxy": "http://user:[email protected]:8080",
"requestId": "example_login_001"
}החליפו את שם המארח, הפעולה והפרוקסי שבדוגמה בערכים של היעד שלכם. בחרו requestId לפני שליחת הבקשה ושמרו אותו לצורך התאוששות מחריגה ממגבלת הזמן; השתמשו בערך חדש לכל משימה לוגית חדשה.
הדוגמה משתמשת בפרוקסי אחד. לחלופין, proxyCandidates מקבל לכל היותר שתים עשרה כתובות URL שונות של פרוקסי HTTP או HTTPS, ללא נתיבים, שאילתות או מקטעים. שלחו שדה אחד או את האחר, לעולם לא את שניהם. המועמדים מאפשרים לשירות לנסות נקודות יציאה חלופיות; הם אינם מבטיחים פרוקסי תקין.
החלפת התשאול והטיפול בחריגות ממגבלת הזמן
המשיכו לטפל במשימות 2Captcha שכבר מתבצעות באמצעות תהליך getTaskResult שלו, עם פרטי האימות, מזהי המשימות ומדיניות התשאול המתועדת שלו. מזהה משימה משירות אחר אינו מזהה משימה של solvethree.
- 1.
טיפול בתגובה ליצירה
בדקו אם תגובת ה-HTTP מציינת אי-הצלחה לפני קריאת תוכן של תגובת הצלחה. יצירת משימת reCAPTCHA ממתינה עד 15 שניות כברירת מחדל, אך עשויה להחזיר משימה שטרם הגיעה למצב סופי. אם היא כבר במצב ready, השתמשו בפתרון בלי להתחיל לולאת תשאול.
- 2.
תשאול רק של משימות שטרם הסתיימו
אחזרו את משימת solvethree באמצעות GET /v1/tasks/:id. החליפו את הבדיקה הישנה של processing בבדיקה של pending ושל solving; שניהם מציינים שהמשימה טרם הסתיימה. רק ready מכיל פתרון שמיש.
- 3.
הגדרת זמן ההמתנה בכתובת ה-URL
תשאול באמצעות GET אינו ממתין כברירת מחדל. לתשאול ארוך, הגדירו את פרמטר השאילתה waitMs בכתובת ה-URL לערך של לכל היותר 15000, ולא כשדה JSON. הגדירו בלקוח ה-HTTP מגבלת זמן שמאפשרת את ההמתנה המבוקשת בתוספת תקורת הרשת.
- 4.
עצירה במצב failed
קראו את errorCode ואת error, ואז הפסיקו לתשאל את המשימה הזו. על פתרונות שנכשלו ניתן החזר. שגיאה כגון site-unreachable מחייבת בדיקה; אל תניחו שכל כישלון נובע מבעיית יתרה ואל תמשיכו לשלוח שוב קלט לא תקין ללא שינוי.
חריגה ממגבלת הזמן של החיבור אינה מוכיחה שהיצירה נכשלה. אם קיבלתם את מזהה המשימה, אחזרו אותה. אם לא, שלחו שוב את אותה בקשה עם אותו requestId כדי לשחזר את המשימה הקיימת במקום ליצור פתרון נוסף. שינוי קלט המשימה תוך שימוש חוזר באותו requestId גורם להתנגשות.
הפרידו במתאם שלכם בין שגיאות HTTP לכשלים סופיים של משימות. מפרט התשאול והטיפול בכשלים מתארים את שני המסלולים האלה; אל תשתמשו שוב במנתח תוכן השגיאות של 2Captcha.
עדכון חילוץ הטוקן ושליחתו
החליפו את חיפוש הטוקן במתאם הישן ב-solution.token ממשימת solvethree במצב ready. שלחו את הטוקן במקום שבו היעד מצפה לערך ה-reCAPTCHA שלו — לא את מזהה המשימה ולא את אובייקט solution כולו.
בעת שליחת הטוקן, השתמשו בזהות הדפדפן שהוחזרה ב-userAgent וב-secChUa, יחד עם הפרוקסי שהצליח. אם סיפקתם proxyCandidates, השתמשו בפרוקסי שהצליח במקום לבחור מועמד אחר לשליחה.
משימה במצב ready פירושה שנוצר פתרון, לא שהאתר קיבל את בקשת האפליקציה שלכם. אם היעד דוחה אותה, בדקו את הטוקן הנשלח, הפעולה, כתובת ה-URL של היעד, הפרוקסי וזהות הדפדפן לפני שתשלמו על פתרון נוסף.
מקורות ותיעוד API
הפעלת המשימה הראשונה שלך.
התחילו עם $5 בקרדיט לסביבת העבודה.