שימוש ב-API המשימות של CAPTCHA ב-Make

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

1. 1.

   הגדירו אימות ב-HTTP v4

   בחרו בסוג האימות API key וצרו מחזיק מפתחות של פרטי הזדהות. הגדירו את Key ל-Bearer ואחריו רווח ומפתח ה-API של סביבת העבודה שלכם, את המיקום ל-In the header ואת שם הפרמטר ל-Authorization. הגבילו את מקורות השירות המורשים ל-https://api.solvethree.com. שמרו את המפתח במחזיק המפתחות במקום להעביר אותו דרך נתוני התרחיש.

2. 2.

   הזינו את הגדרות הבקשה

   השתמשו במתודה, בכתובת ה-URL, בפרמטר השאילתה, בכותרת ובגוף ה-JSON שמוצגים להלן. הזינו כל אחד בשדה המתאים במודול. רק התוכן של body שייך לתוכן בקשת ה-JSON; הדוגמה המלאה היא תצורה להמחשה, ולא תבנית Make שניתן לייבא.

{
  "method": "POST",
  "url": "https://api.solvethree.com/v1/tasks",
  "query": {
    "waitMs": "0"
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "site": "accounts.example.com",
    "action": "login",
    "proxy": "http://USER:PASSWORD@PROXY:PORT",
    "requestId": "one-stable-id-for-this-logical-job"
  },
  "authentication": {
    "type": "API key",
    "Key": "Bearer YOUR_PRIVATE_WORKSPACE_KEY",
    "API key placement": "In the header",
    "API key parameter name": "Authorization",
    "Allowed service origins": [
      "https://api.solvethree.com"
    ]
  }
}

• החליפו את site בשם המארח המוגדר, ולא בכתובת URL מלאה. הגדירו את action לפעולה המשמשת בתהליך היעד.
• החליפו את proxy בכתובת ה-URL של הפרוקסי שלכם. הבקשה מחייבת בדיוק אחד מבין proxy או proxyCandidates; הדוגמה משתמשת בפרוקסי יחיד.
• הקצו לכל עבודה לוגית חדשה requestId משלה, ושמרו אותו לצורך שחזור. הערך שבדוגמה הוא מציין מיקום, ולא מזהה לשימוש חוזר בעבודות שאינן קשורות זו לזו.
• אל תוסיפו type או url לבקשת reCAPTCHA הזו. כאשר recaptchaType מושמט, ברירת המחדל שלו היא enterprise-v3.

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

טפלו בתגובות HTTP שאינן מציינות הצלחה לפני הניתוב לפי מצב המשימה. שגיאת HTTP אינה זהה למשימה שהמצב שלה הוא failed; אל תתייחסו לתגובה שלא ניתן לקרוא או לתגובה לא מוצלחת כאל תוצאת pending נוספת.

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

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

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

1. 1.

   בחרו את מסלול הכניסה

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

2. 2.

   סיימו ריצות שטרם הושלמו

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

3. 3.

   הגבילו כל מנגנון חזרה

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

בבקשת reCAPTCHA הזו, הערך שיש לשלוח הוא solution.token, ולא מזהה המשימה. בעת השליחה ליעד המיועד, השתמשו בזהות הדפדפן userAgent ו-secChUa שהוחזרה, יחד עם הפרוקסי ששימש בהצלחה.

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