HTTPie로 CAPTCHA API 테스트하기
HTTPie로 작업 하나를 생성하고 ID를 저장한 다음 동일한 작업을 조회하세요. 연결 타임아웃이 발생해도 논리적으로 새로운 작업을 생성할 필요가 없도록 POST 전에 requestId를 기록하세요.
이 페이지의 내용
요청 준비하기
- HTTPie와 jq를 설치하고 Bash에서 예제를 실행하세요. 이 명령은 curl이나 curl의 셸 별칭이 아닌 HTTPie의
http실행 파일을 사용합니다. - 환경 변수
SOLVETHREE_API_KEY를 워크스페이스 API 키로 설정하세요. 신뢰할 수 있는 컴퓨터에서 실행하고, 키를 브라우저 코드에 넣지 마세요. - 콘솔에서 대상 호스트 이름에 대한 활성 프로필을 설정하세요. 호스트 이름과 액션을 보내는 것만으로는 프로필이 생성되지 않습니다. 사이트 프로필 설정을 참고하세요.
- 예제 호스트 이름, 액션, 프록시 URL을 바꾸세요. 경로, 쿼리, 프래그먼트가 없는 HTTP 또는 HTTPS 프록시 URL을 사용하세요.
- requestId 자리표시자를 이 논리적 작업의 고유 ID로 바꾸세요. ASCII 문자, 숫자, 밑줄 또는 하이픈으로 구성된 1–64자여야 합니다. 요청을 보내기 전에 저장하세요.
이 요청은 reCAPTCHA Enterprise용이며, recaptchaType의 기본값은 enterprise-v3입니다. site, action과 함께 proxy 또는 proxyCandidates 중 정확히 하나가 필요합니다. 이 예제는 프록시 하나를 사용합니다. type이나 url 필드를 추가하지 마세요.
작업 생성 및 ID 저장하기
set -eu
umask 077
# Install HTTPie and jq. Keep the same request.json for recovery.
cat > request.json <<'JSON'
{
"site": "accounts.example.com",
"action": "login",
"proxy": "http://USER:PASSWORD@PROXY:PORT",
"requestId": "replace-with-one-unique-logical-task-id"
}
JSON
# This file contains proxy credentials; keep it private.
http --check-status --timeout=30 POST https://api.solvethree.com/v1/tasks \
Authorization:"Bearer $SOLVETHREE_API_KEY" waitMs==0 < request.json > task.json
TASK_ID=$(jq -r '.id' task.json)
http --check-status --timeout=30 GET "https://api.solvethree.com/v1/tasks/$TASK_ID" \
Authorization:"Bearer $SOLVETHREE_API_KEY" waitMs==15000
# pending/solving: retrieve the same ID again, within a finite deadline.
# ready: use solution. failed: stop and inspect errorCode/error.
# A timed-out POST is recovered with the unchanged file and requestId.따옴표로 묶인 JSON 문자열은 request.json에 저장되며, HTTPie는 이를 표준 입력에서 읽습니다. Authorization 헤더는 Bearer 인증으로 키를 전송합니다. request.json에는 프록시 자격 증명이 포함되므로 비공개로 유지하세요.
waitMs==0과 waitMs==15000은 JSON 본문 필드가 아닌 HTTPie 쿼리 매개변수입니다. POST는 대기하지 않도록 요청하고, GET은 15,000 ms 대기 시간을 사용합니다. 별도의 HTTPie 옵션인 --timeout=30은 클라이언트 타임아웃을 30초로 설정합니다.
POST 응답은 task.json에 저장되며, jq가 GET에 사용할 id를 추출합니다. 명령을 순서대로 실행하세요. HTTPie가 실패를 보고하면 set -eu가 스크립트를 중단하여 불완전한 응답이 조회에 사용되지 않도록 합니다.
HTTP 성공이 작업 준비 완료를 뜻하지는 않습니다
--check-status는 성공하지 못한 HTTP 응답을 감지합니다. 본문을 성공한 작업 응답으로 취급하기 전에 이를 처리하세요. HTTP 요청이 성공해도 미완료 또는 실패한 작업이 반환될 수 있으므로 다음으로 JSON의 status를 확인하세요.
| 상태 | 다음 작업 |
|---|---|
| 대기 중 또는 해결 중 | 직접 정한 유한한 제한 시간 내에서 동일한 작업 ID를 다시 조회하세요. 아직 준비되지 않았다는 이유만으로 다른 작업을 생성하지 마세요. |
| ready | 반환된 솔루션을 사용하세요. 사용 가능한 솔루션이 있는 상태는 이것뿐입니다. |
| 실패 | 폴링을 중단하고 errorCode와 error를 확인하세요. 해결에 실패한 작업은 환불됩니다. 잘못된 입력을 변경하지 않은 채 무작정 재시도하지 마세요. |
이 예제는 폴링 루프가 아니라 조회를 한 번 수행합니다. 준비된 솔루션을 지정된 대상에 제출할 때는 반환된 userAgent 및 secChUa를 성공한 프록시와 함께 사용하세요. 준비 완료는 solvethree가 솔루션을 생성했다는 뜻이지, 애플리케이션 요청이 성공했다는 뜻은 아닙니다.
타임아웃된 POST 복구하기
클라이언트 타임아웃이 발생했다고 해서 작업 생성이 실패한 것은 아닙니다. 이미 작업 ID가 있다면 해당 작업을 조회하세요. ID를 받기 전에 POST가 타임아웃되었다면 원래 requestId를 포함한 request.json을 변경하지 않고 POST를 다시 실행하세요. 동일한 ID와 작업 입력을 사용하면 기존 작업이 반환됩니다.
비어 있거나 불완전한 task.json에서 ID를 추출하지 말고 먼저 POST를 복구하세요. 해당 requestId를 재사용하면서 프록시, 액션 또는 다른 작업 입력을 변경하지 마세요. 입력이 다르면 충돌이 발생합니다. 논리적으로 새로운 작업을 생성하려는 경우에만 새 requestId를 사용하세요.
첫 작업을 실행하세요.
워크스페이스 크레딧 $5로 시작하세요.