내 Laravel 프로젝트 중 하나의 라이센스 활성화 엔드포인트가 전달된 모든 토큰을 거부하기 시작했습니다. 일부 토큰은 아닙니다. 동일한 서버가 90초 전에 발행한 토큰을 포함한 모든 토큰. 로그에 따르면 token expired. 토큰은 만료되지 않았습니다. 나는 토요일의 대부분을 상자의 시계가 표류했다고 확신하면서 보냈습니다.
It hadn't. 버그는 한 줄이었다:
if (payload.exp < Date.now()) throw new Error('token expired')
exp JWT에서는 초 시대부터 RFC 7519 §4.1.4는 이에 대해 명확합니다. Date.now() javascript가 반환됩니다 밀리초. 그래서 저는 열 자리 숫자를 열세 자리 숫자와 비교하고 있었는데 열 자리 숫자는 항상 더 작습니다. 우주의 모든 토큰은 영원히 만료되었습니다. 수정은 Date.now() / 1000. 실제로는 진단을 받은 적이 없기 때문에 진단에 8시간이 걸렸습니다 바라보다 토큰에서 - 나는 안경을 착용한 상태에서 안경을 검색하는 것과 동일한 디버깅 코드인 내 코드를 계속 다시 읽었습니다.
마침내 루프를 깨뜨린 것은 토큰을 디코더에 붙여넣고 읽는 것이었습니다 exp: 1748952000,그걸 날짜로 변환하고,2 주 후에 타임스탬프를 보는 것. 토큰은 괜찮았습니다. 제 비교는 틀렸습니다. 데이터를 보는 30 초가 코드를 보는 8 시간을 이겼죠.
That's 이 가이드에 대해 무엇. 영리한 디버깅 철학이 아니라 - 내가 "API 디버그,"라는 탭 그룹에 보관하는 특정,지루하고, 화려하지 않은 브라우저 도구 각각은 실제로 무엇을 위해,그리고 그들이 잡는 실패 모드. 여기에 모든 것은에 클라이언트 측을 실행합니다 Toolz.dev당신이're가 붙여넣으려고 하는 것이 프로덕션 베어러 토큰일 때처럼 들리는 것보다 더 중요합니다.
TL;DR: API 가 잘못 동작하면 코드 읽기를 중지하고 페이로드 읽기를 시작합니다. Format the response with the JSON 포맷터. 토큰을 크랙합니다 JWT 디코더일반적인 Base64 도구가 아닌. 회전
exp,iat, 그리고X-RateLimit-Reset실제 데이트로 타임스탬프 변환기. 작업 응답을 깨진 응답과 비교합니다 텍스트 차이 아니면 더 나은 것입니다 JSON 차이점. 쿼리 문자열 맹글링을 디코딩합니다 URL 인코더. 그것의 모두는 당신의 브라우저에서 달린다 - 토큰은 결코 철사를 넘어서지 않는다.
API 디버깅이 코드 디버깅보다 훨씬 더 나쁘다고 느끼는 이유는 무엇입니까?
왜냐하면 당신은 can't 그것을 통해 단계. 로컬 버그는 스택 추적,디버거, 그리고 중단점을 가지고. API 버그는 문자열을 가지고. Somebody else's 서버는 그 문자열을 생산,규칙에 따라 당신은 절반만 알고,당신의 일은 그것에서 거꾸로 작업하는 것입니다.
그게 보통의 스킬을 뒤집어 씁니다. 병목은 isn't 로직,it's 가독성. 거의 모든 API 버그 I & # 39;ve 는 지난 몇 년 동안 내가 데이터를 읽을 수 있도록하기 전까지는 보이지 않았다:
- 4,000자로 축소된 JSON 응답이 있는 것으로 나타났습니다
"data": null깊이 6에 묻혀있습니다. - API가 상태 코드에 넣기에는 너무 정중하다는 오류 메시지로 디코딩된 Base64 페이로드입니다.
- 본문에 내 HTTP 클라이언트가 후행 개행 문자가 있어서 서명 확인에 실패한 웹훅이 유용하게 추가되었습니다.
- 문서들이 초라고 했을 때 밀리초 단위였던 타임스탬프. (Twice. Different companies.)
이 중 어느 것도 어려운 문제는 아니었습니다. 모두 그랬죠 읽을 수 없는 문제. 아래 도구는 당신이 당신의 눈이 과거 슬라이드 것 것을 알아 차릴 정도로 데이터를 읽을 수 있도록 빠르게 존재.
어떤 증상에 대한 어떤 도구?
5 년 전에 누군가 건네줬으면 좋았을 테이블입니다. 왼쪽의 증상,우측의 첫 번째 이동.
| 증상 | What's 는 보통 진실합니다 | 첫 번째 이동 |
|---|---|---|
| 응답은 1 개의 거대한 선, can't 참조 구조입니다 | Nothing's 깨진, it's 그냥 축소 | JSON 포맷터 |
401/403 방금 주조한 토큰에 |
시계, 클레임 또는 비교 버그 | JWT 디코더 → 확인 exp, aud, iss |
| 날짜는 1970년 또는 56122년으로 표시됩니다 | 초/밀리초 불일치 | 타임스탬프 변환기 |
| "어제 효과가 있었어요" | 한 필드가 모양을 바꾸었습니다 | JSON 차이점 오래된 대 새로운 반응 |
| 파람은 엉키거나 잘려 도착합니다 | 이중 인코딩 또는 이스케이프되지 않은 것입니다 &/+ |
URL 인코더 |
| Webhook 서명은 절대 일치하지 않습니다 | 몸 바이트는 무엇과 다르다 you're hashing | 해시 생성기 정확한 생체에 |
Authorization: Basic ... 거부되었습니다 |
잘못 인코딩된 자격 증명 또는 길 잃은 공간 | Base64 변환기 |
| 구성 기반 배포가 실패하고 API가 실행되지도 않습니다 | YAML 들여쓰기 | 야엘 검증인 |
| 두 응답은 동일하게 보이지만 다르게 동작합니다 | 보이지 않는 캐릭터 | 텍스트 차이 |
아래의 모든 것은 그 테이블의 긴 버전입니다.
API 응답을 10초 안에 읽을 수 있도록 하려면 어떻게 해야 합니까?
에 붙여 넣습니다 JSON 포맷터. That's 전체적인 기술,및 I'm 이 glib 이지 않기 - 나가 있는 단 하나 최고 레버리지 벌레잡기 습관은에 거절하고 있다 이유 a 페이로드 I haven't 포맷됨.
Here's 응답 모양 나는 철사에서 나오는 것과 같이 정확하게 청구서 발송 공급자에게서 얻는다:
{"subscriptions":[{"id":"sub_7f3d8a2b","status":"active","plan":{"id":"pro_annual","interval":"year","amount":9900},"current_period_end":1748952000,"cancel_at_period_end":false}],"has_more":false}
포맷된 it's는 완전히 다른 객체입니다. 파서가 아니라 나에게:
{
"subscriptions": [
{
"id": "sub_7f3d8a2b",
"status": "active",
"plan": {
"id": "pro_annual",
"interval": "year",
"amount": 9900
},
"current_period_end": 1748952000,
"cancel_at_period_end": false
}
],
"has_more": false
}
이제 그걸 볼 수 있겠네요 amount 이다 9900 그리고 아닙니다 99.00- it's는 결제 시 가장 일반적인 단일 통합 버그인 센트 단위입니다 current_period_end 는 10 자리 정수이며,이는 초를 의미하며,이는 don't 가 그것을 건네준다는 것을 의미한다 new Date() 직접.
검증은 당신의 눈이 won't 무엇을 잡는다
포맷은 또한 유효성을 검사합니다. 파싱 실패는 정보입니다. 실제 페이로드에 실제로 나타나는 오류:
- 후행 쉼표. JavaScript에서는 합법이고 JSON에서는 불법입니다(당 RFC 8259). 손으로 편집한 정착물은 그들의 가득 차있습니다.
- 작은 따옴표. JSON 은 큰 따옴표가 필요합니다. Python's
str(dict)출력은 아무리 보여도 JSON이 아닙니다. - 인용되지 않은 키. 같은 이야기 - that's 는 JSON 이 아닌 자바스크립트 객체 리터럴입니다.
NaN/Infinity. 일부 직렬화 장치는 그것들을 방출합니다. JSON 은 그러한 리터럴이 없습니다.- 폭탄. 앞에 UTF-8 바이트 순서 표시가 있습니다
{엄격한 파서가 화면에서 완벽하게 보이는 문서를 거부하게 만듭니다.
JSON이 유효하지만 모양 틀렸어요. that's는 다른 도구입니다. 아래 diff 섹션을 참조하세요.
토큰을 Base64로 디코딩하는 대신 JWT 디코더를 사용하는 이유는 무엇입니까?
당신은 Base64-수 손으로 JWT를 디코딩 할 수 있습니다. 나는 수년간 그것을했다. It's 나쁜 습관, 그리고 here's 왜.
JWT (RFC 7519) 는 점으로 구분된 세 개의 청크입니다: 헤더,페이로드, 서명 각 청크는 base64url표준 Base64가 아닙니다 - RFC 4648 §5, 스왑하는 URL 안전 알파벳입니다 +→- 그리고 /→_ 그리고 보통은 떨어뜨립니다 = 패딩. 엄격한 표준-Base64 디코더에 그것을 공급 하 고 오류 또는 자동으로 당신에 게 쓰레기 바이트를 줄 것 이다. 그래서 손 방법은 점 분할, 다시 패딩, 알파벳을 교환, 모든 단일 시간, 그리고 원시 JSON을 눈알을 의미 합니다.
X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X JWT 디코더 그 모든 것을 하나의 붙여넣기에 넣고 - 실제로 시간을 절약해주는 부분 - 주장을 주장으로 제시합니다. 내가 확인하는 것, 순서대로:
exp(만료) 및iat(발행) - 둘 다 숫자 날짜즉. 초 1970-01-01 UTC 부터요. 제 토요일을 먹은 밭입니다.aud(청중) - 스테이징 API용으로 생성된 토큰은 구조적으로 완벽하지만 여전히 prod에서 거부됩니다.iss(발행자) - 신원 제공자 마이그레이션 이후 조용히 변경된 분야입니다.alg헤더에 - 라고 적혀 있으면none는, 당신은 보안 문제가, 디버깅 문제가 아닙니다.
정식 예제 토큰을 가져 가라 everybody's seen:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
헤더: {"alg":"HS256","typ":"JWT"}. 페이로드: {"sub":"1234567890","name":"John Doe","iat":1516239022}. 그리고 iat 있습니다 2018-01-18T01:30:22Z- 다음 섹션의 전체 요점인 타임스탬프 변환기를 통해서만 이를 실행할 수 있습니다.
디코더가 하지 않는 일
디코딩은 검증되지 않습니다. 누구나 JWT; 페이로드는 암호화되지 않고 인코딩됩니다. 디코더는 토큰이 무엇인지 알려줍니다 주장주장 사실 여부를 결코. 서명 확인은 비밀과 함께 서버에서 발생,어떤 브라우저 도구는 이제까지 그 비밀을 건네 줄 수 없습니다. 디코딩 JWT 를 치료 방법 you'd 양식 제출을 취급: 낯선 사람의 주장으로.
타임스탬프 오류를 중지하려면 어떻게 해야 합니까?
숫자 수를 읽는 법을 배웁니다. 이것은 전체 분야에서 가장 저렴한 디버깅 기술이며 배우는 데 1 분이 걸립니다.
| 숫자 | 유닛 | 예 | new Date(x) JS에서는 당신을 제공합니다 |
|---|---|---|---|
| 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 X 10 | 초 | 1748952000 |
1970-01-21 - 분명히 틀렸습니다 |
| 13 | 밀리초 | 1748952000000 |
정확한 날짜 |
| 16 | 마이크로초 | 1748952000000000 |
말도 안되는 소리 |
열 자리는 초를 뜻합니다. 열 세 자리는 밀리초를 뜻합니다. JavaScript's Date 생성자는 밀리초를 원한다; 유닉스,파이썬's time.time(), Go's Unix(), PHP's time()그리고 대부분의 API' exp 필드는 초를 말합니다. 그 불일치의 하류에 있는 모든 것은 혼돈입니다.
그리고 혼돈은 한 방향에서는 시끄럽고 다른 방향에서는 침묵합니다. 먹이 초 밀리 초 파서에 당신은 1970 을 얻을 - 너무 명백한 버그는 분에 그것을 해결합니다. 피드 밀리초 a에게 초 파서와 당신은 연도를 얻습니다 56122. 나는 확인했다: 1708876200000초로 해석하면 56122년 2월 17일에 착륙합니다. That's는 조용히 배송되는 방향입니다. 왜냐하면 아무것도 던지지 않기 때문입니다. 구독은 단순히 만료되지 않으며 분기 동안 아무도 눈치채지 못합니다.
X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 타임스탬프 변환기 존재하므로 논쟁하는 대신 하나의 붙여 넣기로 해결할 수 있습니다. 붙여 넣기 1748952000, 날짜를 읽고, 계속 진행하세요. 붙여넣기 X-RateLimit-Reset api 가 불평하는 헤더를 작성하고 4 시간이 아니라 4 분 동안 기다려야한다는 것을 알게됩니다. 타임스탬프가 순진한 경우 (아니오 Z오프셋 없음) 그리고 다른 지역에서 그것이 무엇을 의미하는지 추론해야 합니다 시간대 변환기 는 후속.
알만한 가치가 있는 타임스탬프 트랩이 두 개 더 있습니다
2038 년 문제는 실제적이고 날짜가 있습니다. 부호 있는 32비트 초 카운터가 오버플로됩니다 2147483647, 이는 2038-01-19T03:14:07Z. 서명된 32 비트 int 에 아직도 시간을 저장하는 어떤 체계든지 - 그리고 누구든 인정하고 싶은 보다는 끼워넣어진과 유산 데이타베이스 란에 있는 그들중 더 많은 것이 있다 - 그때 끊는다. 만약에 you're 설정 장수 만기 오늘,당신은 이미 이것을 명중할 수 있다.
순진한 타임스탬프는 생략에 의한 거짓말입니다. 2026-02-25T14:30:00 후행 없음 Z 그리고 아니 +05:30 는 시간상의 순간이 아니다; it's 불특정 장소에서의 순간. 나는 순진한 타임스탬프를 반환하는 모든 API 를 제출 대기 중인 버그 리포트로 취급한다. RFC 3339 를 선호한다 (2026-02-25T14:30:00Z)는 웹이 실제로 사용하는 ISO 8601의 엄격하고 명확한 프로필입니다.
What Do I Do When "어제 효과가 있었어"?
그것을 차이. Don't 이론화 - diff it.
작업환경에서 응답을 붙잡으십시오 (또는 당신의 통나무에서 마지막 좋은 것을 파내십시오) 그리고 끊긴 것에게서 응답을,그리고 나란히 두십시오. 10 의 9 배 정확하게 1 개의 다름이 있고 it's 는 5 초 안에 당신을 응시합니다.
JSON의 경우 다음을 확인하세요 JSON 차이점 텍스트 diff 전에요. 양변을 구문 분석하고 비교합니다 구조이는 재정렬된 키와 다른 들여쓰기 don't가 변경 사항으로 표시됨을 의미합니다. 실제 항목만 변경됩니다. 다른 키 순서로 직렬화된 서버가 크리스마스 트리처럼 켜지고 아무 것도 알려주지 않는 두 JSON 문서의 텍스트 차이입니다.
모든 것을 위해 isn't JSON - 헤더, 원시 본문, 구성 파일, curl 출력 - 를 사용합니다 텍스트 차이. 그것의 특기는 당신의 눈이 물리적으로 붙잡을 수 없는 변화의 종류입니다: 뒤에 오는 공간,4 개의 공간이 된 탭,Windows 기계에서 몰래 들어온 CRLF 선 끝,당신이 예를 베낄 때 문서 사이트가 똑바른 것을 대용한 꼬부라진 인용에 I've 는 전체적인 조각을 위에 썼습니다 눈알 텍스트 비교가 실패하는 이유, 지원 에스컬레이션 비용이 한 번 들었기 때문입니다.
왜 내 쿼리 매개 변수가 계속 깨져 도착합니까?
URL 인코딩에는 3~4개의 미묘하게 다른 맛이 있고 everybody's 스택은 다른 맛을 선택하기 때문입니다.
얼마나 자주 they've 물린 나에 대한 대략적인 순서의 고전:
+대%20. 쿼리 문자열에서,+역사적으로 공간을 의미합니다(theapplication/x-www-form-urlencoded컨벤션). 경로 세그먼트에서,+는 리터럴 플러스를 의미합니다. 그래서 를 포함하는 base64 서명+인코딩되지 않은 쿼리 문자열에 삭제된 는 공백이 포함된 상태로 도착하고 서명 확인이 실패합니다. 값이 있기 때문에 이것은 정말 불쾌한 것입니다 보인다 바로 로그에 있습니다.- 이중 인코딩.
%2F된다%252F스택의 두 레이어가 모두 유용하게 인코딩했기 때문입니다. 증상은 프록시를 통과할 때마다 퍼센트-기호를 얻는 매개변수입니다. - 생것
&값 내부. 매개변수를 두 개로 나눕니다. 이제name=Ben & Jerry이다name=Ben게다가 미스터리 파라라는 것도 있습니다Jerry.
URL을 에 붙여넣습니다 URL 인코더 그리고 그것을 해독하십시오. 한 번 해독하는 것이 아직도 퍼센트-탈출을 뒤에 남겨두는 경우에,you've 는 당신의 두 배 부호화를 찾아냈습니다. That's 전체적인 진단.
Won't 인증 웹훅을 어떻게 디버그합니까?
이것은 "를 분리하는 것입니다 HTTP"를 "에서 I've been on call."
거의 모든 웹훅 제공자는 HMAC 로 페이로드를 서명하고 헤더에 결과를 넣습니다. 당신의 임무는 동일한 HMAC 를 계산하고 비교하는 것입니다. does't 가 일치하면 서명이 거의 문제가되지 않습니다. 바이트가 문제다. 당신은 그들이 해시한 것을 해싱하고 있지 않습니다.
일반적인 용의자:
- 구문 분석 및 재직렬화된 본문을 해시했습니다. 프레임워크는 JSON을 호출한 개체로 구문 분석했습니다
JSON.stringify()그것에,그리고 지금 키 순서 또는 공백은 1 개의 특성에 의해 다릅니다. 당신은 해시해야 합니다 생 요청 본문, 수신된 바이트. Express에서 이는 이전에 원시 버퍼를 캡처하는 것을 의미합니다express.json()도착; Laravel에서는 의미합니다$request->getContent(), 아니다$request->all(). - 후행 개행. 일부 클라이언트는 하나를 추가합니다.The provider didn't.
- You're 는 원시 바이트 대신 16 진수 인코딩된 문자열을 해싱합니다또는 16진수를 base64와 비교합니다.
- 샤셋. 신체는 멀티바이트 특성을 갖고 있으며 그 과정에서 무언가가 이를 트랜스코딩했습니다.
X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 해시 생성기 이것을 분리하는 방법은 다음과 같습니다: 정확한 본문 문자열을 가져와서 해시하고 내 코드가 생성한 것과 비교해 보세요 생각 는 같은 본문이었다. 그 두 해시가 다른 경우,내 코드는 내가 생각하는 바이트를보고 있지 않습니다 it's 보고,문제는 전혀 암호화되지 않았습니다. (또한 알 가치가: 공급자가 여전히 MD5 또는 SHA-1 서명을 제공하는 경우,that's 그들의 플랫폼의 나이에 대한 신호. SHA-256 지금 바닥입니다.)
디버그 탭 그룹에는 또 무엇이 있나요?
조연 - 덜 화려하지만 여전히 그 자리를 차지하고 있습니다:
- UUID 생성기- 청소를 위해
X-Request-ID모든 테스트 호출에서,그래서 당신은 세 가지 services' 에 걸쳐 grep 수 있습니다; 나중에 로그. UUIDs 사양 새로 고침을 가지고 알고 가치가: RFC 9562 (2024) 더 이상 사용되지 않습니다 RFC 4122 그리고 표준화되었습니다 UUIDv7이는 시간 순서가 지정되어 있으므로 무작위 v4보다 데이터베이스's B-트리 인덱스에 훨씬 더 친절합니다. iF you're picking a ID scheme for new table today, that's the one to read up. There's a UUID 버전의 긴 분석 원한다면. - Base64 변환기- 을 위한
Authorization: Basic헤더(RFC 7617: it'sbase64(user:password)그리고,그렇다, that's 인코딩,보안이 아니라 - TLS 가 그것을 보호하는 것이다), 그리고 인라인 바이너리 blobs 에 대한 일부 APIs 물건을 JSON 필드로. Base64 는 당신에게 ~ 33% 크기의 오버헤드를 요한다,이는 왜 "unexpectedly large" 페이로드가 종종 단지 그 안에 파일을 가지고 있는 이유이다. The 전체 Base64 가이드 사람을 위로 여행 base64url 구분을 다룹니다. - 야엘 검증인- 작년에 내 API 실패의 절반이 't API 실패였기 때문입니다. CI 구성에서 두 공간 들여쓰기 오류였으며 엔드포인트는 전혀 배포되지 않았습니다. (YAML은 깨진 빌드보다 더 심각한 실패 모드를 가지고 있지만: valid YAML은 당신이 한 일을 의미합니다.'t 의도. 나는 썼다 왜
version: 1.101.1 이 됩니다 배포 비용이 발생한 후.) - 정규식 테스터- 순간 당신은 패턴 you'에 대한 확신이없는 로그의 900 줄에서 요청 ID 를 뽑아해야합니다.
- CSV 뷰어- 누군가가 생산으로 수입하기 전에 생산량을 온전하게 확인해야 하는 수출 종점의 경우.
이것이 브라우저에서 실행되는 것이 실제로 중요합니까?
예, 그리고 I & # 39;d는 내가 hadn & # 39;t 사이트를 구축 한 경우에도이 말을.
디버깅 도구에 붙여넣는 것을 생각해 보세요. A JWT - which is a 라이브 자격 증명 만료될 때까지. 고객 데이터인 프로덕션 API 응답: 이름,이메일, 구독 상태. 결제 레코드를 포함할 수 있는 웹훅 본문. A curl 명령 Authorization 헤더가 아직 남아 있습니다.
이제 서버측 툴이 정의에 의해 그 모든 것을 수신한다고 생각해보자. 악의적으로가 아니라 - 단지 구조적으로. 붙여넣기는 HTTP 요청에 들어가서 someone's 백엔드를 치고,그들이 우연히 실행하게 되는 어떤 로깅에도 착륙한다. 꼼꼼하게 정직한 운영자조차도 그들이 결코 보관하려고 의도하지 않은 액세스 로그에 베어러 토큰을 넣게 된다.
Toolz.dev 에 있는 도구는 탭에서 자바스크립트로 작업을 합니다. 아무것도 업로드되지 않습니다. 왜냐하면 there's 아무데도 업로드할 곳이 없기 때문입니다 - 구문 분석,디코딩, 해싱은 모두 여러분의 머신에서 일어납니다. You don't have to take my word for that,one: open DevTools,go to Network tab,paste a token,and watch for a request thatnever comes.That's a thirty-second audit,and you should run it on 어떤 도구 당신은에 비밀을 붙여 넣기, 내 포함. 나는 썼다 클라이언트 측 도구를 올바르게 확인하는 방법 바로 이런 이유에서.
귀하의 조직이 EU 개인 데이터를 처리하는 경우, 이것은 isn't 만 위생 - 고객 기록을 타사 서버에 붙여 넣는 것은 모든 GDPR 서류 작업을 암시하는 처리 활동입니다. 클라이언트 측 도구는 전혀 프로세서가되지 않음으로써 질문을 회피합니다.
실제로 달라붙는 워크플로
여섯 단계, 순서에 나는 그들을 실행할 때 something's 에 불이:
- 원시 응답을 캡처합니다. 전신,전체 헤더,상태 코드. 하지 당신의 app's 해석 그것의-실제 바이트.
curl -i또는 네트워크 탭's "cURL."로 복사 - 포맷하세요. JSON 포맷터. 을 보세요 모양 값을 보기 전에,필요한 분야가 존재하는가?
- 모든 불투명 문자열을 디코딩합니다. 토큰을 통해 JWT 디코더, Base64가 얼룩을 통과합니다 Base64 변환기, URL이 엉망이 되었습니다 URL 인코더. 불투명한 문자열은 놀라울 정도로 자주 답을 숨깁니다.
- 시간이 될 수 있는 모든 숫자를 날짜로 바꿉니다. 타임스탬프 변환기. 먼저 숫자를 세어보세요.
- 알려진 좋은 반응에 비해 다릅니다. JSON 차이점. 당신이 don't 알려진-좋은 응답이 있는 경우에,이것은 그들을 저장 하기 시작 하는 당신의 표시 이다.
- 이제서야 가서 코드를 읽어보세요. 이 시점에서 당신은 일반적으로 당신이 파일을 열기 전에 줄을 알고있다.
순서가 중요합니다. 6 단계는 제가 시작했던 곳이고,그 토요일이 왜 여덟 시간이 걸렸는지 it's 입니다.
자주 묻는 질문
API를 디버깅하기 위한 최고의 무료 도구는 무엇입니까?
일상적인 API 디버깅을 위해서는 다섯 가지가 필요합니다: JSON 포맷터와 유효성 검사기,JWT 디코더,유닉스 타임스탬프 컨버터,diff 툴,URL 인코더/디코더. 다섯 가지 모두 Toolz.dev 에서 무료이며 브라우저에서 완전히 실행됩니다. 서명된 웹훅으로 작업하는 경우 해시 생성기를 추가하고 배포가 구성 기반인 경우 YAML 유효성 검사기를 추가합니다.
JWT 또는 API 응답을 온라인 도구에 붙여넣는 것이 안전한가요?
도구가 클라이언트 측 인 경우에만. JWT 는 라이브 자격 증명이며 API 응답은 일반적으로 고객 데이터이므로 서버 측 도구는 stranger's 백엔드로 모두 배송하는 것을 의미합니다. Toolz.dev 도구는 브라우저의 모든 것을 JavaScript 로 처리하고 네트워크를 통해 아무 것도 보내지 않습니다 - DevTools' 를 열어 직접 확인; 붙여 넣는 동안 네트워크 탭. 민감한 데이터와 함께 사용하는 모든 도구에서 동일한 검사를 실행하십시오.
JWT에서 방금 생성했을 때 "expired"라고 말하는 이유는 무엇입니까?
가장 흔한 원인은 단위 불일치입니다. The exp claim 은 초 단위 (RFC 7519 에서는 NumericDate 로 정의) 이지만 JavaScript's 입니다 Date.now() 밀리초를 반환하므로 직접 비교하면 모든 토큰이 만료된 것처럼 보입니다.Decode the token, read exp을, 타임스탬프 변환기로 실제 날짜로 변환하고, 인증 코드를 터치하기 전에 실제로 과거인지 확인하십시오.
Unix 타임스탬프가 초 단위인지 밀리초 단위인지 어떻게 알 수 있나요?
숫자를 세어보세요. 열 자리는 초,열세 개는 밀리초,열여섯 개는 마이크로초입니다. 만약 날짜가 1970 년에 나온다면 당신은 초를 밀리초 파서에 먹였습니다; 만약 56122 년에 나온다면 당신은 밀리초를 초 파서에 먹였습니다. 두 번째 실수는 더 위험합니다. 왜냐하면 아무것도 오류를 던지지 않기 때문입니다.
이러한 도구를 사용하여 GraphQL API 를 디버깅할 수 있습니까?
예. GraphQL 응답은 JSON 이므로 JSON 포맷터와 JSON diff 는 변경되지 않고 작동하며 GraphQL 은 일반적으로 JWT 디코더로 동일한 베어러 토큰 인증 you'd 디코드를 사용합니다. 유일한 실제 차이점은 GraphQL 이 HTTP 200 을 반환한다는 것입니다 errors 2xx가 아닌 상태 대신 배열을 사용하므로 항상 본문 형식을 지정하십시오. 실패는 상태 코드가 아닌 페이로드 내부에 있습니다.
웹훅 서명 확인이 항상 실패하는 이유는 무엇입니까?
거의 항상 제공자와 다른 바이트를 해싱하고 있기 때문입니다. 프레임워크가 JSON 본문을 구문 분석한 후 해싱 전에 다시 직렬화하면 공백 또는 키 순서가 변경되어 HMAC 가 일치하지 않습니다. 원시 요청 본문을 수신한 그대로 해시하고 HTTP 클라이언트가 추가한 후행 개행 문자를 확인하세요.
Base64와 base64url 인코딩의 차이점은 무엇입니까?
표준 Base64(RFC 4648 §4) 사용 + 그리고 / 알파벳과 패드로 되어 있습니다 =. base64url (RFC 4648 §5) 는으로 그들을 대체합니다 - 그리고 _ 그리고 보통 패딩을 떨어뜨리기 때문에,값은 URL 이나 JWT 에 넣어도 안전합니다. base64url 데이터를 엄격한 표준-Base64 디코더에 공급하면 오류나 가비지가 발생하기 때문에 전용 JWT 디코더가 토큰을 핸드 디코딩하는 것을 이깁니다.
401 Unauthorized 응답을 어떻게 디버깅합니까?
토큰에서 바깥쪽으로 작업합니다. 해독하고 확인하십시오 exp 현재 시간에 비해 만료된 토큰은 가장 일반적인 원인이며 청구를 읽을 수 있는 날짜로 변환할 때까지는 보이지 않습니다. 토큰이 활성 상태인 경우 토큰을 확인하세요 Authorization 헤더 자체: 구성표가 있어야 하며 철자가 정확해야 합니다(Bearer <token>, 한 칸, 따옴표 없음) 및 터미널에서 붙여넣은 토큰에는 종종 일치 항목을 깨는 후행 개행 문자가 표시됩니다. 그 후 확인 aud 그리고 iss 다른 잠재 고객을 위해 발급 된 유효한 토큰이 나쁜 토큰과 똑같이 거부되기 때문에 주장은 API 가 기대하는 것과 일치합니다. 그런 다음 서버를 의심하기 시작합니다.
라이브러리가 없는 JWT를 어떻게 디코딩합니까?
JWT 는 점으로 결합된 3 개의 base64url 세그먼트입니다. 점에 분할하고,그 후에 base64url-처음 2 개 - 우두머리 및 페이로드를 해독하십시오 - 및 둘 다 평야 JSON 로 나오십시오. 제 3 세그먼트는 서명이고,텍스트 보다는 오히려 익지않는 바이트이기 때문에 읽을 수 있는 아무것도로 해독하지 않습니다. 이것은 소리가 나는 보다는 더 중요합니다: 토큰을 해독하는 것은 그 주장이 진실하다는 것을 아닙니다 주장하는 무슨을 당신에게 말합니다. 서명을 확인하는 것은 issuer's 열쇠를 요구하고 당신의 서버 부호에서 속하고,결코 브라우저 공구에 있는 토큰을 여기에서 읽기; 신청에서 그들을 유효하게 하십시오.
이 도구를 사용해도 Postman이나 Insomnia가 필요합니까?
예 - 그들은 다른 문제를 해결합니다. API 클라이언트는 요청을 보냅니다; 이러한 도구는 응답을 읽을 수있게합니다. 실제로 나는 클라이언트를 사용하여 요청을 실행하고 원시 출력을 복사 한 다음 브라우저 도구로 이동하여 포맷,디코딩, 변환 및 차이점을 대체하지 않고 워크 플로우에서 서로 옆에 앉습니다.
