נקודת קצה להפעלת רישיון באחד מפרויקטי Laravel שלי התחילה לדחות כל אסימון שנמסר. לא כמה אסימונים. כל אסימון, כולל כאלה שאותו שרת הוציא תשעים שניות קודם לכן. נכתב ביומנים token expired. האסימונים לא פג. ביליתי את רוב שבת משוכנע שהשעון על הקופסה נסחף.
זה hadn't. הבאג היה שורה אחת:
if (payload.exp < Date.now()) throw new Error('token expired')
exp ב-JWT הוא שניות seconds מאז התקופה - RFC 7519 §4.1.4 חד משמעי לגבי זה. Date.now() ב-javascript חוזר אלפיות שניות. אז השוויתי מספר בן עשר ספרות מול מספר בן שלוש עשרה ספרות, ומספרים בני עשר ספרות תמיד קטנים יותר. כל אסימון ביקום פג, לנצח. התיקון היה Date.now() / 1000. האבחנה ארכה שמונה שעות כי אני אף פעם לא באמת הסתכל באסימון - המשכתי לקרוא שוב את הקוד שלי, שהוא המקבילה לניפוי באגים לחיפוש המשקפיים שלך בזמן הרכבתם.
מה ששבר לבסוף את הלולאה היה הדבקת האסימון במפענח, קריאה exp: 1748952000, להמיר את זה לדייט, ולראות חותמת זמן שבועיים בעתיד האסימון היה בסדר ההשוואה שלי הייתה שגויה שלושים שניות של הסתכלות על נתונים ניצחו שמונה שעות של הסתכלות על קוד.
That's על מה המדריך הזה. לא פילוסופיית איתור באגים חכמה - כלי הדפדפן הספציפיים, המשעממים והלא זוהרים שאני שומר בקבוצת כרטיסיות בשם "API Debug," למה בעצם כל אחד מהם מיועד, ומצבי הכשל שהם תופסים. הכל כאן פועל בצד הלקוח Toolz.dev, מה שחשוב יותר ממה שזה נשמע כמו שזה עושה כאשר הדבר שאתה ' עומדים להדביק הוא אסימון נושא הפקה.
TL;DR: כאשר API מתנהג בצורה לא נכונה, הפסק לקרוא את הקוד שלך והתחל לקרוא את המטען. עצב את התגובה עם פורמט JSON. לפצח את האסימון עם ה מפענח JWT, לא כלי Base64 גנרי. לפנות
exp,iat, וX-RateLimit-Resetלתוך דייטים אמיתיים עם ה ממיר חותמת זמן. השווה תגובת עבודה מול תגובת עבודה שבורה עם ה הבדל טקסט או, יותר טוב, ה JSON Diff. פענוח שאילתות-מחרוזת מתבלבל עם מקודד URL. כל זה פועל בדפדפן שלך - האסימון אף פעם לא עובר על החוט.
מדוע איתור באגים ב-API מרגיש הרבה יותר גרוע מקוד ניפוי באגים?
כי אתה יכול't לעבור דרכו באג מקומי יש עקבות מחסנית, מאתר באגים, ונקודת שבירה באג API יש מחרוזת.Somebody other's שרת הפיק את המחרוזת הזו, לפי כללים שאתה רק חצי יודע, והתפקיד שלך הוא לעבוד אחורה ממנו.
זה הופך את המיומנות הרגילה. צוואר הבקבוק הוא 't logic, it's קריאות. כמעט כל באג API I' רדפתי בשנים האחרונות היה בלתי נראה עד שהפכתי את הנתונים לקריאה:
- תגובת JSON ממוזערת בת 4,000 תווים שהתבררה כבעלת
"data": nullנקבר בעומק שש. - מטען Base64 שפוענח להודעת שגיאה את ה-API היה מנומס מכדי להכניס לקוד המצב.
- וו אינטרנט שנכשל באימות חתימה מכיוון שלגוף היה קו חדש נגרר שלקוח ה-HTTP שלי הוסיף בצורה מועילה.
- חותמת זמן שהייתה באלפיות שניות כשהדוקטורים אמרו שניות. (פעמיים. חברות שונות.)
אף אחת מאלה לא הייתה בעיות קשות כולן היו בלתי קריא בעיות הכלים שלהלן קיימים כדי להפוך את הנתונים קריאים מספיק מהר כדי שתבחין בדבר שעיניך היו מחליקות מעבר לו.
איזה כלי לאיזה סימפטום?
זה השולחן הלוואי שמישהו היה מוסר לי לפני חמש שנים סימפטום משמאל, קודם תזוזה מימין.
| הסימפטום | מה's בדרך כלל נכון | מהלך ראשון |
|---|---|---|
| התגובה היא קו ענק אחד, יכול' לא רואה מבנה | Nothing's שבור, it's פשוט ממוזערים | פורמט JSON |
401/403 על אסימון שהרגע הטבעת |
באג שעון, תביעה או השוואה | מפענח JWT → בדוק exp, aud, iss |
| התאריך מופיע כ-1970 או שנת 56122 | אי התאמה של שניות/מילישניות | ממיר חותמת זמן |
| "זה עבד אתמול" | שדה אחד שינה צורה | JSON Diff תגובה ישנה לעומת חדשה |
| פרמים מגיעים מעוותים או קטומים | קידוד כפול, או בלתי נמלט &/+ |
מקודד URL |
| חתימת Webhook אף פעם לא תואמת | בתים בגוף שונים ממה שאתה 're hashing | מְחוּגָה על הגוף הגולמי המדויק |
Authorization: Basic ... נדחה |
אישורים מקודדים לא נכון, או רווח תועה | ממיר Base64 |
| פריסה מונעת תצורה נכשלת, API אפילו לא פועל | הזחה YAML | מאמת יאמל |
| שתי תגובות נראות זהות אך מתנהגות אחרת | דמות בלתי נראית | הבדל טקסט |
כל מה שלמטה הוא הגרסה הארוכה של הטבלה ההיא.
כיצד אוכל להפוך תגובת API לקריאה בעשר שניות?
הדבק אותו לתוך ה פורמט JSON. That's כל הטכניקה, ו-I'm לא להיות glib - הרגל ניפוי הבאגים היחיד בעל המינוף הגבוה ביותר שיש לי הוא לסרב סיבה לגבי מטען שיש לי 't מעוצב.
Here' היא צורת תגובה שאני מקבל מספק חיוב, בדיוק כשהיא יורדת מהחוט:
{"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' הוא אובייקט אחר לגמרי - לא למנתח, אלא לי:
{
"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 הוא מספר שלם בן עשר ספרות, שפירושו שניות, שפירושו don't למסור אותו ל new Date() ישירות.
אימות תופס את מה שהעיניים שלך זכו 't
עיצוב גם מאמת כשל בניתוח הוא מידע השגיאות שמופיעות בפועל במטענים אמיתיים:
- פסיקים נגררים. חוקי ב-JavaScript, לא חוקי ב-JSON (לפי RFC 8259). מתקנים בעריכה ידנית מלאים בהם.
- ציטוטים בודדים. JSON דורש מרכאות כפולות. Python's
str(dict)הפלט הוא לא JSON, לא משנה כמה הוא נראה כמוהו. - מפתחות לא מצוטטים. אותו סיפור - that's אובייקט JavaScript מילולי, לא JSON.
NaN/Infinity. כמה serializers פולטים אותם.JSON אין מילוליים כאלה.- בום. סימן UTF-8 בתים לפני
{יגרום למנתח קפדני לדחות מסמך שנראה מושלם על המסך.
אם ה-JSON שלך תקף אבל ה צורה שגוי, זה ' הוא כלי אחר - ראה את הסעיף הבדל למטה.
מדוע להשתמש במפענח JWT במקום רק Base64-פענוח האסימון?
אתה יכול Base64-פענוח JWT ביד.עשיתי את זה במשך שנים.It's הרגל רע, ו כאן's למה.
JWT (RFC 7519) הוא שלושה נתחים המופרדים על ידי נקודות: כותרת, מטען, חתימה. כל נתח הוא base64url, לא Base64 סטנדרטי - RFC 4648 §5, האלפבית הבטוח לכתובת URL שמחליף +→- ו /→_ ובדרך כלל מפיל את = ריפוד. הזינו את זה למפענח סטנדרטי קפדני של Base64 וזה יטעה או ייתן לכם בשקט בתים של זבל. אז שיטת היד פירושה פיצול על נקודות, ריפוד מחדש והחלפת האלפבית, בכל פעם, ואז גלגל עיניים של JSON גולמי.
ה מפענח JWT עושה את כל זה בהדבקה אחת ו - החלק שלמעשה חוסך זמן - מציג את הטענות כטענות. the one I check, in order:
exp(תפוגה) וiat(הונפק ב) - שניהם NumericDate, כלומר. שניות seconds מאז 1970-01-01 UTC. זה השדה שאכל את השבת שלי.aud(קהל) - אסימון שהוטבע עבור ממשק ה-API שלך יהיה מושלם מבחינה מבנית ועדיין נדחה על ידי prod.iss(מנפיק) - לאחר הגירה של ספק זהות, זה התחום שהשתנה בשקט.algבכותרת - אם כתובnone, יש לך בעיית אבטחה, לא בעיית ניפוי באגים.
קח את אסימון הדוגמה הקנונית everyone's seen:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
כותרת: {"alg":"HS256","typ":"JWT"}. מטען: {"sub":"1234567890","name":"John Doe","iat":1516239022}. ו iat יש 2018-01-18T01:30:22Z- שאתה מכיר רק על ידי הפעלתו דרך ממיר חותמת זמן, שהוא כל הפואנטה של הקטע הבא.
הדבר שמפענח לא עושה
פענוח אינו מאמת כל אחד יכול לפענח JWT; המטען מקודד, לא מוצפן מפענח אומר לך מה האסימון טענות, לעולם לא אם הטענה נכונה. אימות חתימה מתרחש בשרת שלך עם הסוד שלך, ואף כלי דפדפן לא צריך להיות מוסר את הסוד הזה. Treat a decoded JWT the way you'd reat a form submission: as a assertion from a stranger.
איך אני מפסיק לטעות בחותמות זמן?
למד לקרוא את ספירת הספרות זוהי מיומנות ניפוי הבאגים הזולה ביותר בכל התחום ולוקח דקה אחת ללמוד.
| ספרות | יחידה | דוגמה | new Date(x) ב-JS נותן לך |
|---|---|---|---|
| 10 | שניות seconds | 1748952000 |
1970-01-21 - ברור שגוי |
| 13 | אלפיות שניות | 1748952000000 |
התאריך הנכון |
| 16 | מיקרו שניות | 1748952000000000 |
שטויות |
עשר ספרות פירושן שניות שלוש עשרה משמעותן אלפיות שניות.JavaScript's Date constructor רוצה אלפיות שניות; Unix, Python's time.time(), Go's Unix(), PHP's time(), ורוב ממשקי ה-API' exp שדות מדברים שניות הכל במורד הזרם של חוסר ההתאמה הזה הוא כאוס.
והכאוס רועש בכיוון אחד ושותק בכיוון השני. להאכיל שניות seconds לנתח של אלפיות שנייה ואתה מקבל 1970 - באג כל כך ברור שאתה מתקן אותו בדקה. להאכיל אלפיות שניות ל א שניות seconds מנתח ואתה מקבל את השנה 56122. בדקתי: 1708876200000, המתפרש כשניות, נוחת ב-17 בפברואר בשנת 56122. That' זה הכיוון שנשלח בשקט, כי שום דבר לא זורק - מנוי פשוט לא יפוג ואף אחד לא שם לב במשך רבע.
ה ממיר חותמת זמן קיים כך שתוכל ליישב זאת במשחה אחת במקום להתווכח על כך. Paste 1748952000, קרא את התאריך, המשך הלאה הדבק את X-RateLimit-Reset header ה-API שלך מתלונן עליו וגלה שיש לך ארבע דקות לחכות, לא ארבע שעות. אם חותמת הזמן נאיבית (לא Z, אין קיזוז) ואתה צריך לנמק מה זה אומר באזור אחר, ה ממיר אזור זמן הוא המעקב.
עוד שתי מלכודות חותמת זמן שכדאי להכיר
בעיית 2038 היא אמיתית ומתוארכת. מונה חתום של 32 סיביות שניות עולה על גדותיו בשעה 2147483647, כלומר 2038-01-19T03:14:07Z. כל מערכת שעדיין מאחסנת זמן ב-int חתום של 32 סיביות - ויש יותר מהם בעמודות מסד נתונים משובצות ומדור קודם ממה שמישהו רוצה להודות - נשברת אז. אם אתה 'הגדרת תפוגות ארוכות חיים היום, אתה כבר מסוגל להכות את זה.
חותמות זמן נאיביות הן שקר בהשמטה. 2026-02-25T14:30:00 בלי נגרר Z ולא +05:30 אינו רגע בזמן; it's רגע במקום לא מוגדר אני מתייחס לכל API שמחזיר חותמות זמן נאיביות כדוח באג שמחכה להגשה מעדיף RFC 3339 (2026-02-25T14:30:00Z), שהוא הפרופיל הקפדני והחד משמעי של ISO 8601 שהרשת משתמשת בו בפועל.
מה אני עושה כאשר "זה עבד אתמול"?
הבדל את זה. Don't משערים - הבדל את זה.
ללכוד את התגובה מסביבת העבודה (או לחפור את הטוב האחרון מתוך היומנים שלך) ואת התגובה מהשבור, ולשים אותם זה לצד זה. תשע פעמים מתוך עשר יש בדיוק הבדל אחד וזה 's בוהה בך תוך חמש שניות.
עבור JSON, הושט יד אל JSON Diff לפני הבדל הטקסט. זה מנתח את שני הצדדים ומשווה מבנה, שפירושו מפתחות מסודרים מחדש והזחה שונה don't מופיעים כשינויים - רק אמיתיים מופיעים. הבדל טקסט של שני מסמכי JSON ששרת מסודר בסדר מפתח אחר יידלק כמו עץ חג המולד ולא יגיד לך כלום.
לכל מה שהוא't JSON - כותרות, גופים גולמיים, קבצי תצורה, curl פלט - השתמש ב הבדל טקסט. המומחיות שלו היא סוג השינוי שהעיניים שלך אינן מסוגלות לתפוס פיזית: רווח נגרר, לשונית שהפכה לארבעה רווחים, סיום קו CRLF שהתגנב ממכשיר Windows, ציטוט מתולתל שאתר תיעוד החליף אתר ישר אחד כשהעתקת את הדוגמה. I'כתבתי עליו מאמר שלם מדוע השוואות טקסט עם גלגלי עיניים נכשלות, כי זה עלה לי פעם אחת בהסלמה בתמיכה.
מדוע פרמטרי השאילתה שלי ממשיכים להגיע שבורים?
מכיוון שלקידוד כתובת URL יש שלושה או ארבעה טעמים שונים בתכלית וכולם ' מחסנית בוחרת אחד אחר.
הקלאסיקות, בסדר גס של התדירות שבה הן 'נשכו אותי:
+לעומת%20. במחרוזת שאילתה,+היסטורית פירושו מרחב (הapplication/x-www-form-urlencodedמוסכמה). בקטע נתיב,+פירושו פלוס מילולי. אז חתימת base64 המכילה+, ירד למחרוזת שאילתה לא מקודדת, מגיע עם רווחים בתוכה ובדיקת החתימה נכשלת. זה באמת מגעיל כי הערך נראה ממש ביומנים.- קידוד כפול.
%2Fהופך%252Fכי שתי שכבות של הערימה שלך שניהם קידדו אותו בצורה מועילה הסימפטום הוא פרמטר שצובר סימני אחוז בכל פעם שהוא עובר דרך פרוקסי. - גלם
&בתוך ערך. מפצל את הפרמטר שלך לשניים. עַכשָׁיוname=Ben & Jerryהואname=Benבנוסף פרם מסתורי שנקראJerry.
הדבק את כתובת האתר לתוך מקודד URL ולפענח אותו. אם פענוחו פעם אחת עדיין משאיר אחוז-בורח מאחור, אתה & #39;מצאתי הקידוד הכפול שלך. That's כל האבחון.
כיצד אוכל לנפות באגים ב-Webhook שזכה 't לאמת?
זה זה שמפריד בין "אני מבין HTTP" מ-"I'היה בכוננות."
כמעט כל ספק webhook חותם על המטען עם HMAC ומכניס את התוצאה לכותרת. התפקיד שלך הוא לחשב את אותו HMAC ולהשוות. כאשר זה מתאים 't, החתימה היא כמעט אף פעם לא הבעיה. הבתים הם הבעיה. אתה לא hashing מה שהם hashed.
החשודים הרגילים:
- גיבית את הגוף המנותח-והמסודר מחדש. המסגרת שלך ניתחה את ה-JSON לאובייקט, התקשרת
JSON.stringify()עליו, ועכשיו סדר המפתחות או הרווח הלבן שונה בתו אחד אתה חייב hash את גלם גוף בקשה, בתים כפי שהתקבל. ב-Express זה אומר ללכוד את המאגר הגולמי לפניexpress.json()מגיע לזה; בלארוול זה אומר$request->getContent(), לא$request->all(). - קו חדש נגרר. חלק מהלקוחות מצרפים אחד. הספק עשה 't.
- You're גיבוב של המחרוזת המקודדת משושה במקום הבתים הגולמיים, או השוואת hex מול base64.
- צ'ארסט. לגוף יש אופי מרובה בתים ומשהו לאורך הדרך העביר אותו.
ה מְחוּגָה הוא איך אני מבודד את זה: קח את מחרוזת הגוף המדויקת, גיבוב זה, השווה מול מה שהקוד שלי הפיק עבור מה שהוא מחשבה היה אותו גוף אם שני הגיבובים האלה שונים, הקוד שלי הוא לא לראות את הבתים אני חושב שזה 's לראות, והבעיה מעולם לא הייתה קריפטוגרפית בכלל. (גם שווה לדעת: אם ספק עדיין מציע חתימות MD5 או SHA-1, that's אות לגבי גיל הפלטפורמה שלהם.SHA-256 הוא הרצפה עכשיו.)
מה עוד חי בקבוצת Debug Tab?
צוות המשנה - פחות זוהר, עדיין מרוויח את מקומו:
- מחולל UUID- לניקוי
X-Request-IDבכל שיחת בדיקה, כך שתוכל לשפר אותה על פני שלושה שירותים ' יומנים לאחר מכן. שווה לדעת ש-UUIDs קיבלו רענון מפרט: RFC 9562 (2024) מיושן RFC 4122 וסטנדרטית UUIDv7, שהוא מסודר בזמן ולכן אדיב בהרבה למסד הנתונים שלך 's B-tree index מאשר v4 אקראי. אם אתה ' בוחרים היום ערכת זיהוי לטבלה חדשה, that's זה שיש לקרוא עליו. שם's א פירוט ארוך יותר של גרסאות UUID אם אתה רוצה את זה. - ממיר Base64- עבור
Authorization: Basicכותרות (RFC 7617: it'sbase64(user:password), וכן, זה & #39; קידוד s, לא אבטחה - TLS הוא מה שמגן עליו), ועבור הכתמים הבינאריים המוטבעים כמה דברים של ממשקי API לתוך שדות JSON. Base64 עולה לך תקורה בגודל של ~33%, וזו הסיבה ש-" " גדול באופן בלתי צפוי; למטען יש לעתים קרובות רק קובץ ב- מדריך Base64 מלא מכסה את ההבחנה base64url שמכשילה אנשים. - מאמת יאמל- כי מחצית מתקלות ה-API שלי בשנה האחרונה היו 't כשלים ב-API. הם היו שגיאת הזחה של שני רווחים בתצורת CI, ונקודת הקצה מעולם לא נפרסה כלל. (ל-YAML יש מצב כשל מגעיל יותר מאשר מבנה שבור, אם כי: YAML חוקי זה אומר משהו שעשית ' לא מתכוון. כתבתי למה
version: 1.10הופך ל-1.1 אחרי שזה עלה לי בפריסה.) - בודק רגקס- כרגע אתה צריך לשלוף מזהה בקשה מתוך 900 שורות יומן עם דפוס שאתה ' לא בטוח לגביו.
- מציג CSV- לנקודת הקצה של הייצוא שאת התפוקה שלה אתה צריך לבדוק את השפיות לפני שמישהו מייבא אותה לייצור.
האם זה באמת משנה שאלו פועלים בדפדפן?
כן, ו-I'd תגיד את זה גם אם הייתי 't בנה את האתר.
תחשוב על מה שאתה מדביק לתוך כלי ניפוי באגים. A JWT - שהוא א אישור חי עד שתפוג תגובת API לייצור, שהיא נתוני לקוחות: שמות, מיילים, מצבי מנוי גוף webhook, שעשוי להכיל רשומת תשלום.A curl פקודה עם א Authorization כותרת עדיין בתוכו.
עכשיו שקול שכלי בצד השרת, בהגדרה, מקבל את כל זה. לא בזדון - רק מבחינה ארכיטקטונית. הדבק נכנס לבקשת HTTP, פוגע במישהו 's backend, ונוחת בכל רישום שהוא מפעיל במקרה. אפילו מפעיל ישר בקפדנות מסיים עם אסימון הנושא שלך ביומן גישה שמעולם לא התכוונו לשמור.
הכלים ב-Toolz.dev עושים את העבודה ב-JavaScript בכרטיסייה שלך שום דבר לא מועלה, כי שם' אין לאן להעלות את זה - הניתוח, הפענוח, הגיבוב קורים כולם במחשב שלך. אתה עושה ' לא צריך לקחת את המילה שלי גם בשביל זה: פתח את DevTools, עבור ללשונית רשת, הדבק אסימון וצפה בבקשה שלעולם לא מגיעה. That' הוא ביקורת של שלושים שניות, ואתה צריך להפעיל אותו כל כלי שאתה מדביק סודות לתוכו, שלי כלול. כתבתי כיצד לאמת כלי בצד הלקוח כראוי בדיוק מהסיבה הזאת.
אם הארגון שלך מטפל בנתונים אישיים של האיחוד האירופי, זה ' t רק היגיינה - הדבקת רשומות לקוחות בשרת צד שלישי היא פעילות עיבוד, עם כל הניירת של GDPR שמשתמעת מכך. כלים בצד הלקוח עוקפים את השאלה בכך שהם לעולם לא הופכים למעבד כלל.
זרימת עבודה שבעצם נדבקת
שישה שלבים, לפי הסדר שאני מפעיל אותם כשמשהו' בוער:
- ללכוד את התגובה הגולמית. גוף מלא, כותרות מלאות, קוד סטטוס. Not your app's interpretation of it - the actual bytes.
curl -iאו הכרטיסייה Network's "העתק כ-cURL." - לעצב אותו. פורמט JSON. תראה את צורה לפני שאתה מסתכל על הערכים האם השדה שאתה צריך בכלל נוכח?
- פענח כל מחרוזת אטומה. אסימונים דרך ה מפענח JWT, Base64 כתמים דרך ממיר Base64, כתובות URL מעוותות דרך מקודד URL. מחרוזות אטומות מסתירות את התשובה לעתים קרובות באופן מפתיע.
- הפוך כל מספר שיכול להיות זמן לתאריך. ממיר חותמת זמן. ספר תחילה את הספרות.
- להבדיל נגד תגובה ידועה-טובה. JSON Diff. אם אתה עושה ' אין לך תגובה ידועה-טובה, זה הסימן שלך להתחיל לשמור אותם.
- רק עכשיו לך תקרא את הקוד שלך. בשלב זה אתה בדרך כלל יודע את השורה לפני שאתה פותח את הקובץ.
הסדר משנה. שלב 6 הוא המקום שבו נהגתי להתחיל, וזה 's למה שבת ההיא לקחה שמונה שעות.
שאלות נפוצות
מהם הכלים החינמיים הטובים ביותר לאיתור באגים בממשקי API?
עבור ניפוי באגים יומי API אתה צריך חמישה דברים: מעצב JSON ומאמת, מפענח JWT, ממיר חותמת זמן Unix, כלי הבדל ומקודד/מפענח URL. כל החמישה חינמיים ב-Toolz.dev ופועלים לחלוטין בדפדפן. הוסף מחולל hash אם אתה עובד עם webhooks חתומים, ומאמת YAML אם הפריסות שלך מונעות תצורה.
האם זה בטוח להדביק תגובת JWT או API בכלי מקוון?
רק אם הכלי הוא צד לקוח JWT הוא אישור חי ותגובת API היא בדרך כלל נתוני לקוח, כך שכלי בצד השרת פירושו משלוח שניהם ל-stranger's backend. כלי Toolz.dev מעבדים הכל בדפדפן שלך עם JavaScript ולא שולחים דבר דרך הרשת - אמת זאת בעצמך על ידי פתיחת DevTools' לשונית רשת בזמן שאתה מדביק. הפעל את אותה בדיקה בכל כלי שבו אתה משתמש עם נתונים רגישים.
מדוע ה-JWT שלי אומר "פג תוקף" כשרק יצרתי את זה?
הסיבה השכיחה ביותר היא אי התאמה של יחידות. ה exp הטענה היא תוך שניות (RFC 7519 מגדיר זאת כ-NumericDate), אך JavaScript's Date.now() מחזירה אלפיות שניות, אז השוואה ביניהם ישירות גורמת לכל מראה אסימון לפוג. פענח את האסימון, קרא exp, המר אותו לתאריך אמיתי עם ממיר חותמת זמן, ובדוק אם הוא אכן בעבר לפני שאתה נוגע בקוד האישור שלך.
כיצד אוכל לדעת אם חותמת זמן של Unix היא תוך שניות או אלפיות שניות?
ספור את הספרות עשר ספרות זה שניות שלוש עשרה זה אלפיות שניות שש עשרה זה מיקרו שניות אם יוצא תאריך ב1970 האכלת שניות למנתח אלפיות שניות; אם זה יוצא בשנת 56122 האכלת אלפיות שניות למנתח שניות הטעות השנייה מסוכנת יותר כי שום דבר לא זורק שגיאה.
האם אוכל להשתמש בכלים אלה כדי לנפות באגים בממשקי API של GraphQL?
כן. תגובות GraphQL הן JSON, כך שמעצב JSON ו-JSON diff עובדים ללא שינוי, ו-GraphQL משתמש בדרך כלל באותו אימות עם סמל נושא you' d לפענח עם מפענח JWT. ההבדל האמיתי היחיד הוא ש-GraphQL מחזיר HTTP 200 עם errors מערך במקום מצב שאינו 2xx, אז תמיד לעצב את הגוף - הכשל הוא בתוך המטען, לא בקוד המצב.
מדוע אימות חתימת ה-webhook שלי תמיד נכשל?
כמעט תמיד כי אתה hashing בתים שונים ממה שהספק עשה אם המסגרת שלך ניתחה את גוף JSON ואתה מחדש serialized זה לפני hashing, רווח הלבן או סדר מפתח השתנה ואת HMAC לעולם לא יתאים. Hash גוף הבקשה הגולמי בדיוק כפי שהתקבל, ולבדוק עבור שורה חדשה נגררת שנוספה על ידי לקוח HTTP שלך.
מה ההבדל בין קידוד Base64 ו-base64url?
שימושים ב-Standard Base64 (RFC 4648 §4) + ו / באלפבית שלו ורפידות עם =. base64url (RFC 4648 §5) מחליף את אלה ב - ו _ ובדרך כלל מפיל את הריפוד, כך הערך בטוח לשים ב URL או JWT. הזנת נתונים base64url למפענח סטנדרטי-Base64 קפדני מייצרת שגיאה או זבל, וזו הסיבה מפענח JWT ייעודי מנצח פענוח יד אסימון.
כיצד אוכל לנפות באגים בתגובה 401 לא מורשית?
עבודה כלפי חוץ מהאסימון פענח אותה ובדוק exp כנגד הזמן הנוכחי - אסימון שפג תוקפו הוא הסיבה היחידה הנפוצה ביותר, והוא בלתי נראה עד שאתה ממיר את התביעה לתאריך קריא אם האסימון חי, בדוק את Authorization הכותרת עצמה: הסכימה חייבת להיות נוכחת ומאויתת כהלכה (Bearer <token>, רווח אחד, ללא ציטוטים), ואסימון המודבק ממסוף נושא לעתים קרובות קו חדש נגרר ששובר את ההתאמה. לאחר מכן, אשר את aud ו iss תביעות תואמות את מה שה-API מצפה, מכיוון שאסימון תקף שהונפק לקהל אחר נדחה בדיוק כמו רע רק אז התחל לחשוד בשרת.
איך אני מפענח JWT ללא ספרייה?
JWT הוא שלושה מקטעי base64url שמצטרפים אליהם נקודות. split on the dots, then base64url-decode the first two - the header and the payload - and both come out as plain JSON.The third segment is the signature, and it does not decode into anything readable because it is raw bytes vather than text.This matters more than it sounds: decoding a token tells you what it claims, not whether these claims are true.Verifying the signature requires the issueer's key and likes in your server code, never in a browser tool.Read tokens here to d
האם אני עדיין צריך דוור או נדודי שינה אם אני משתמש בכלים האלה?
כן - הם פותרים בעיות שונות לקוח API שולח בקשות; הכלים האלה הופכים את התגובות לקריאות. בפועל אני משתמש בלקוח כדי לפטר את הבקשה ולהעתיק את הפלט הגולמי, ואז עובר לכלי דפדפן כדי לעצב, לפענח, להמיר ולהבדיל אותו. הם יושבים זה ליד זה בזרימת העבודה במקום להחליף אחד את השני.
