Make에서 CAPTCHA 작업 API 사용하기

먼저 워크스페이스에서 대상 호스트 이름의 활성 프로필을 설정하세요. site와 action을 전송하는 것만으로는 프로필이 생성되지 않습니다. 대상이 아직 설정되지 않았다면 사이트 프로필 설정을 참고하세요.

1. 1.

   HTTP v4 인증 설정

   인증 유형으로 API key를 선택하고 인증 정보 키체인을 만드세요. 키 값은 Bearer 뒤에 공백과 워크스페이스 API 키를 붙여 설정하고, 위치는 In the header, 매개변수 이름은 Authorization으로 설정하세요. 허용된 서비스 출처를 https://api.solvethree.com으로 제한하세요. 키를 시나리오 데이터로 전달하지 말고 키체인에 보관하세요.

2. 2.

   요청 설정 입력

   아래에 표시된 메서드, URL, 쿼리 매개변수, 헤더, JSON 본문을 사용하세요. 각각 해당하는 모듈 필드에 입력하세요. JSON 요청 콘텐츠에는 body의 내용만 넣어야 합니다. 전체 예시는 설명용 설정이며, 가져올 수 있는 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를 부여하고 복구를 위해 보관하세요. 예시 값은 자리표시자이며, 서로 관련 없는 작업에서 재사용할 ID가 아닙니다.
• 이 reCAPTCHA 요청에 type이나 url을 추가하지 마세요. recaptchaType을 생략하면 기본값은 enterprise-v3입니다.

생성 응답이 성공하면 추가 작업을 진행하기 전에 반환된 작업 ID를 해당 논리적 작업과 연결해 저장하세요. 해당 작업을 조회할 별도의 HTTP 요청 모듈을 추가하세요.

작업 상태에 따라 라우팅하기 전에 성공이 아닌 HTTP 응답을 처리하세요. HTTP 오류는 상태가 failed인 작업과 다릅니다. 읽을 수 없거나 성공하지 않은 응답을 또 다른 pending 결과로 취급하지 마세요.

GET이 성공하면 반환된 status에 명시적인 필터를 적용하는 라우터를 추가하세요. 성공한 모든 HTTP 응답을 솔루션 경로로 보내지 마세요.

미완료 상태 필터를 모든 나머지 경우를 처리하는 필터로 만들지 말고 명시적으로 유지하세요. 상태가 없거나 예상과 다르면 확인해야 하며, 아무 처리 없이 무한히 폴링해서는 안 됩니다. 실패 경로에서는 다른 작업을 생성하기 전에 보고된 오류를 조사하세요. 잘못된 입력을 변경하지 않으면 재시도해도 나아지지 않습니다.

범위가 제한된 간단한 설계는 폴링 실행당 GET을 한 번 수행합니다. 다음 실행에서 읽을 수 있는 곳에 미완료 작업을 저장하세요. 현재 실행에만 존재하는 작업 ID에 의존하지 마세요.

1. 1.

   진입 경로 선택

   작업에 이미 작업 ID가 있다면 바로 GET으로 이동하세요. 기존 작업이 없는 새 작업만 생성 경로로 진입해야 합니다.

2. 2.

   미완료 상태의 실행 종료

   pending 또는 solving이면 작업 ID를 유지하고 실행을 종료하세요. 재개할 때는 동일한 ID를 조회하세요. 종료 상태의 작업은 닫힘으로 표시해 이후 폴링 실행에서 결과를 다시 처리하지 않도록 하세요.

3. 3.

   반복 횟수 제한

   대신 반복기를 추가한다면 유한한 최대 횟수를 설정하고 저장된 ID의 GET만 반복하세요. ready 또는 failed 이후에는 추가 폴링이나 결과 처리를 막으세요. 반복 한도에 도달하면 중단하고 ID를 유지해야 하며, 대체 작업을 생성해서는 안 됩니다.

이 reCAPTCHA 요청에서 제출할 값은 작업 ID가 아니라 solution.token입니다. 의도한 대상에 제출할 때는 성공한 프록시와 함께 반환된 userAgent 및 secChUa 브라우저 식별 정보를 사용하세요.

Make의 HTTP 모듈이 최종 요청에서 솔버에 제공한 고객 프록시를 사용할 수 있다고 가정하지 마세요. 필요한 프록시와 브라우저 식별 정보를 지원하는 클라이언트에 준비된 결과를 전달하세요. ready는 솔루션이 생성되었음을 의미합니다. 수락 여부는 이후 제출에 대한 대상의 응답으로 결정됩니다.