המשימה מוכנה. מדוע טוקן ה-reCAPTCHA נדחה?

{
  "id": "example-task",
  "status": "ready",
  "solution": {
    "token": "EXAMPLE_TOKEN",
    "userAgent": "EXAMPLE_USER_AGENT",
    "secChUa": "EXAMPLE_CLIENT_HINTS"
  }
}

בדוגמה הזו, solution.token הוא הערך שיש לשלוח במקום שבו אתר היעד מצפה לטוקן reCAPTCHA שלו. id מזהה את משימת solvethree; הוא אינו טוקן. אל תשלחו גם את אובייקט הפתרון כולו.

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

הטוקן שנשלח נכון, אך אתר היעד עדיין דוחה אותו.

השוו את שם המארח של האתר במשימה לשם המארח של הבקשה המוגנת. בדקו אם מדובר בתת-דומיין אחר או בסביבה אחרת.

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

טוקן שהתבקש עבור אינטראקציה אחת משמש לאינטראקציה אחרת.

השוו את הפעולה של המשימה לפעולה המדויקת המצופה בבקשה המוגנת הזו.

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

האינטגרציה משתמשת בגרסת reCAPTCHA שגויה.

בדקו את recaptchaType בבקשת המשימה. ברירת המחדל שלו היא enterprise-v3; השער מקבל גם v3.

כדאי לנסות: התאימו במפורש למוצר של היעד. עבור Enterprise v3, השתמשו ב-enterprise-v3.

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

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

הפתרון מצליח, אך השליחה מתבצעת דרך חיבור אחר.

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

כדאי לנסות: שלחו דרך הפרוקסי שהצליח. החלפת כתובות IP בין הפתרון לשליחה עלולה להכשיל את הבקשה.

הלקוח השולח משתמש בכותרות הדפדפן שלו המוגדרות כברירת מחדל.

בדקו את ערכי User-Agent ו-Sec-CH-UA היוצאים מול solution.userAgent ו-solution.secChUa.

כדאי לנסות: השתמשו בזהות הדפדפן שהוחזרה יחד עם הפרוקסי שהצליח. אל תשלבו את הטוקן עם ערכי user-agent או client-hint שאינם קשורים אליו.

בדקו את גוף התגובה של היעד וגם את סטטוס ה-HTTP שלו. קוד 403 לבדו אינו מצביע על מנגנון ההגנה שדחה את הבקשה. חפשו שגיאת טוקן מפורשת או אי-התאמה בשם המארח או בפעולה לפני שתבקשו טוקן נוסף.

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

אם עדיין אינכם מצליחים לזהות את הסיבה, פנו ל[email protected] עם מזהה המשימה ו-requestId אם נעשה בו שימוש, המוצר, חותמת הזמן, שם המארח והפעולה של היעד, סטטוס ה-HTTP או שגיאת המשימה, ותיאור התגובה לאחר הסרת מידע רגיש. הסירו מפתחות API, סיסמאות פרוקסי, טוקנים, עוגיות ונתוני לקוחות.