이 HTTP 서명 계산기가 하는 일
"우리가 계산한 요청 서명은 당신이 제공한 서명과 일치하지 않는다"는 것은 API 작업에서 가장 좌절스러운 오류 중 하나입니다. 왜냐하면 서버가 어떤 단계가 잘못되었는지 결코 알려주지 않기 때문입니다. 이 계산기는 AWS Signature Version 4, Alibaba Cloud ACS3-HMAC-SHA256, Tencent Cloud TC3-HMAC-SHA256 및 OAuth 1.0a HMAC-SHA1의 전체 서명 프로세스를 복제하고 모든 중간 값을 보여줍니다: 정규 요청, 해시, 서명 문자열, 파생 서명 키 및 최종 서명 및 헤더. 또한 GitHub, Stripe 및 Slack에서 들어오는 **webhook 서명 **를 확인합니다. 모든 암호는 브라우저의 웹 암호 API를 사용합니다. 비밀 키는 장치에 남아있습니다.
사용 방법
- 공급자 탭을 선택하세요.
- 메소드, URL, 헤더 (선당 1
Name: value) 및 본체를 코드에서 전송된 대로 입력합니다. - 액세스 키, 비밀 키 및 해당 지역 및 서비스를 입력합니다. 현재 시간을 사용하라를 클릭하거나 고정된 시간표를 붙여 캡처된 요청과 비교합니다.
- 각 단계를 SDK나 코드 로그와 비교해 보세요. 첫 번째 다른 단계는 여러분의 버그가 어디에 있는지입니다.
- 웹후크를 위해, 원시 요청 본부 바이트에 바이트, 서명 헤더와 서명 비결을 붙여넣고, 도구가 일치하는지 여부를 알려줍니다.
서명이 일치하지 않는 흔한 원인
- 기본적인 URI 코딩: AWS는 각 경로 세그먼트를 코딩합니다. S3는 이중 코딩을 하지 않습니다.
- ** 질의 순서:** 매개 변수는 암호화 키에 의해 정렬되어야 하며, 빈 값은 여전히
=이 필요합니다. - ** 서명 된 헤더:** 헤더 이름은 소문자로, 잘라서, 정렬하고
;과 결합됩니다.host나x-amz-date를 잊어버리는 것은 흔한 일입니다. - 용량 해시: S3는
x-amz-content-sha256헤더를 필요로 합니다. 다른 서비스는 몸만 해시합니다. - 시계 오차: 대부분의 공급자는 5~15분 이상 요청을 거부합니다.
- ** 웹후크:** 프레임워크는 JSON을 보기 전에 분석하고 다시 시리즈화합니다. 재코딩된 객체가 아닌 원시 바이트를 확인하세요. 스트라이프 신호
timestamp.body, 슬랙 신호v0:timestamp:body.