הפסדתי אחר צהריים פעם אחת לכתובת URL שנראתה בסדר התקשרות חוזרת של OAuth המשיכה להיכשל, ההפניה מחדש URI "matched" זה שנרשם אצל הספק, ולא יכולתי לראות מדוע לחיצת היד נשברה התשובה, כאשר לבסוף הדבקתי את הדבר במנתח, הייתה קו נטוי נגרר על השביל במקום אחד ואף אחד במקום השני, בתוספת א state פרמטר שקודד כך כפול %20 הפך %2520. לעין האנושית שתי כתובות האתרים היו זהות. לשרת OAuth הם היו מחרוזות שונות, ונכון היה לדחות את חוסר ההתאמה.
זו הבעיה עם כתובות אתרים: הן צפופות, קל לקרוא אותן לא נכון, והפרטים ששוברים דברים - קו נטוי מקודד, יציאה תועה, מפתח שאילתה חוזר, קטע שבו ציפית לנתיב - הם בדיוק אלה ש מסתתר בקיר של תווים. אני בונה [Toolz.dev] (/, ואני מבלה מספיק זמן בבהייה במחרוזות שאילתות תוך כדי ניפוי באגים שבניתי א מנתח כתובת URL כדי לעשות לי את הבהייה הדבק קישור, קבל כל רכיב מסומן וכל פרמטר שאילתה מפוענח בטבלה מדריך זה מסביר מהם הרכיבים הללו, מדוע ההבחנות חשובות וכיצד להשתמש בהם.
TL;DR: כתובת URL עשויה מתכנית (
https), אישורים אופציונליים (user:pass@), מארח (example.com) עם יציאה אופציונלית, נתיב (/blog/post), מחרוזת שאילתה (?id=42), ושבר (#section). ה מנתח כתובת URL מפצל כל קישור לחלקים אלה באמצעות הדפדפן ' מנוע כתובת האתר WHATWG משלו, מפענח את השאילתה לטבלת ערכי מפתח מסודרת (מפתחות חוזרים ונשנים נשמרים בנפרד), מציג את היציאה האפקטיבית עבור הסכימה ומניחhttps://אם אתה מדביק דומיין חשוף. זה פועל כולו בדפדפן שלך, כך שקישורים עם אסימונים נשארים פרטיים.
מהם החלקים של כתובת URL?
כל כתובת URL עוקבת אחר אותו דקדוק, המוגדר על ידי WHATWG URL Standard - דפדפני המפרט מיישמים בפועל. ברגע שאתה יכול לתת שם לחלקים, רוב באגי ה-URL הופכים ברורים. הנה האנטומיה המלאה, תוך שימוש בדוגמה עמוסה בכוונה:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
לפרק את זה:
| רכיב | ערך לדוגמה | מה זה |
|---|---|---|
| תכנית | https |
הפרוטוקול.מחליט יציאת ברירת מחדל וכיצד הבקשה נעשית. |
| שם משתמש | john |
אישור אופציונלי, לפני ה @. |
| סיסמה | s3cret |
אישור אופציונלי, לאחר ה : במידע המשתמש. |
| שם מארח | shop.example.co.uk |
הדומיין או כתובת ה-IP, ללא יציאה. |
| נמל | 8443 |
אופציונאלי. נופל חזרה לברירת המחדל של הסכימה כאשר הושמט. |
| מארח | shop.example.co.uk:8443 |
שם מארח פלוס יציאה, כאשר קיימת יציאה. |
| מוצא | https://shop.example.co.uk:8443 |
Scheme plus host - דפדפני היחידה המשמשים לאבטחה. |
| נתיב | /catalog/shoes |
מיקום המשאב במארח. |
| שאילתה | ?color=red&size=42 |
פרמטרים של ערך מפתח לאחר ה ?. |
| פרגמנט | #reviews |
עוגן בצד הלקוח לאחר ה #, מעולם לא נשלח לשרת. |
המנתח מניח כל אחד מאלה כשורה משלו עם כפתור העתקה, כך שלעולם לא תצטרך לחלץ שוב שם מארח מכתובת URL של מפלצת. זה גם מסמן כמה דברים שהמחרוזת הגולמית מסתירה: האם היציאה המוצגת מפורשת או סכימה 's ברירת מחדל, והאם המארח הוא דומיין בעל שם או IP גולמי.
מה ההבדל בין שם מארח, מארח ומקור?
שלושת האנשים האלה מכשילים כל הזמן, והבלבול גורם לבאגים אמיתיים - כשלים ב-CORS, טעויות בהיקף עוגיות, אי-התאמות של הפניות מחדש. הם לא מילים נרדפות. ה תקן כתובת URL של WHATWG האם ההגדרה שדפדפנים מיישמים בפועל, וזה המקום ליישב ויכוח על מה שנחשב כמקור.
שם מארח האם רק הדומיין או ה-IP: shop.example.co.uk. אין יציאה, אין סכימה. זה מה שהיית שם בחיפוש DNS.
מארח האם שם המארח בתוספת היציאה, אבל רק כאשר קיימת יציאה בכתובת האתר. ל shop.example.co.uk:8443 המארח הוא shop.example.co.uk:8443. למישור https://shop.example.co.uk/ המארח ושם המארח זהים, מכיוון שיציאת ברירת המחדל 443 משתמעת ולא כתובה. זה " רק כאשר נוכח" הכלל הוא עדין וזו הסיבה שלאותו אתר יכולים להיראות שני מארחים שונים.
מוצא האם סכימה פלוס מארח: https://shop.example.co.uk:8443. זה הדבר שדפדפנים הכי דואגים לו, מכיוון שמדיניות אותו מקור - הבסיס לאבטחת אינטרנט - משווה מקורות, לא שמות מארח. שתי כתובות URL חולקות מקור רק אם הסכימה שלהן, שם המארח, ו פורט כל התאמה. http://example.com ו https://example.com הם מקורות שונים מכיוון שהתוכנית שונה. https://example.com ו https://example.com:8443 האם מקורות שונים מכיוון שהיציאה שונה, למרות ששם המארח זהה. אם אחזור נכשל עם שגיאת CORS, השוואת שני המקורות זה לצד זה במנתח היא בדרך כלל הדרך המהירה ביותר לזהות את חוסר ההתאמה.
איך אני מנתח מחרוזת שאילתה?
מחרוזת השאילתה היא המקום שבו חי רוב הכאב היום-יומי, מכיוון שמדובר בכתם שטוח, חסר מראה, שהוא למעשה מובנה ומקודד באחוזים. המנתח מפצל אותו עבורך: הכל אחרי ה ?, שבור &, עם כל אחד key=value זוג פוענח ורשום בטבלה בסדר המקורי שלה.
שתי התנהגויות חשובות כאן. ראשית, פענוח. פרמטר שנכתב כ q=trail%20runner על החוט מוצג כ trail runner בעמודת הערך, כי %20 הוא מרחב מקודד באחוזים. הגולמי search מחרוזת עדיין מוצגת ללא נגיעה ברשימת הרכיבים, כך שתוכל להשוות בין הטפסים המקודדים והמפענחים - לא יסולא בפז כאשר אתה חושד בקידוד כפול, כמו שלי %2520 באג OAuth.
שנית, מקשים חוזרים. כתובת URL יכולה לשאת באופן לגיטימי את אותו מפתח יותר מפעם אחת: ?tag=react&tag=typescript&tag=node. מנתחים תמימים רבים מכווצים את אלה, שומרים רק על הערך הראשון או האחרון ומאבדים נתונים בשקט. זה שגוי - מפתחות חוזרים הם האופן שבו טפסי HTML שולחים שדות מרובי בחירה וכיצד הרבה ממשקי API מבטאים מערכים. המנתח שומר על כל התרחשות כשורה משלו, לפי הסדר, כך שאתה רואה את כל שלושת התגים. כאשר אתה מעתיק את השאילתה כ-JSON, מפתחות חוזרים הופכים למערך, שזו הצורה שרוב הקוד מצפה לה.
אתה אפילו לא צריך כתובת URL מלאה כדי להשתמש בזה. הדבק רק מחרוזת שאילתה - color=red&size=42 - והכלי מנתח את זה לבד זו הדרך המהירה ביותר שאני מכיר להבין מטען webhook או קישור מעקב שמישהו העביר לך.
כיצד אוכל להשתמש במנתח כתובת האתר?
הכלי נועד לצאת מגדרך הדבק כתובת URL בקלט הבודד והוא מנתח בשידור חי תוך כדי הקלדה - אין כפתור ללחוץ על קישור לדוגמה נטען מראש כך שתוכל לראות את הפירוט המלא באופן מיידי, וכפתור נקה מרוקן את השדה.
אתה לא צריך להקליד את התוכנית. הדבק מארח חשוף כמו example.com/pricing והמנתח מקדים https:// באופן אוטומטי, ואז אומר לך שזה עשה זאת עם הערה קטנה, כך שאתה אף פעם לא מבולבל לגבי מאיפה התוכנית הגיעה. הדבק סכימה מפורשת - http://, ftp://, ssh:// - וזה מכבד את זה במקום.
לפלט ארבעה אזורים. בחלק העליון, ה כתובת אתר מנורמלת - הצורה הקנונית של הדפדפן 's מנוע מיוצר, עם כפתור העתקה, שהוא שימושי לתפיסת הבדלי נורמליזציה עדינים. מתחת לזה, ה רכיבים טבלה, שורה אחת מסומנת לכל חלק, כל אחת ניתנת להעתקה עצמאית. לאחר מכן מקטעי נתיב, שבור לשבבים באינדקס אז נתיב עמוק כמו /api/v2/users/42/orders קריא במבט חטוף לבסוף ה פרמטרי שאילתה טבלה, מפוענחת ומסודרת, עם "copy בתור JSON" פעולה שהופכת את כל השאילתה לאובייקט נקי.
הכל פועל בדפדפן שלך באמצעות מנוע ה-URL המקורי שלו. זו בחירה מכוונת: כתובות URL מכילות באופן שגרתי אסימוני גישה, מזהי הפעלה, פרמטרים חתומים ושמות מארח פנימיים, ושום דבר מזה לא צריך להישלח לשרת רק כדי לקרוא. שום דבר שאתה מדביק לא עוזב את המכשיר שלך, והכלי ממשיך לעבוד במצב לא מקוון. זוהי אותה גישה פרטית ראשונה מאחורי כל ערכת הכלים, שאליה אני נכנס מדריך ערכת כלים למפתחי אינטרנט.
מתי אני מושיט יד למנתח כתובות אתרים?
כמה מצבים עולים שוב ושוב בעבודה שלי. ניתוב מחדש של איתור באגים והתקשרויות חוזרות הוא הגדול - זרימות OAuth, כתובות אתרים להחזרת תשלום, לחיצות ידיים של SSO, שכולן נכשלות באי-התאמות זעירות שהופכות גלויות רק כאשר אתה מפרק את שתי כתובות האתרים. ביקורת קישורי מעקב הוא אחר: כתובות URL שיווקיות הן לעתים קרובות דף בסיס בתוספת תריסר פרמטרים של UTM ופלטפורמת מודעות, וקריאתן כטבלה מנצחת את הפזילה למחרוזת של 300 תווים. אם אתה בונה את הקישורים האלה במקום לקרוא אותם, ה בונה UTM הוא החצי השני של אותו זרימת עבודה.
ואז יש עבודת API - בדיקת פרמטרי השאילתה שלקוח שלח בפועל, או הנדסה לאחור כיצד נקודת קצה מצפה למסננים שלה. ו סקירת אבטחה: קישור לא מוכר בדואל או ביומן הוא הרבה יותר בטוח להבנה על ידי ניתוח החלקים שלו (מה המארח עושה זאת באמת נקודה ב? is that hostname an IP?) מאשר על ידי לחיצה עליו המנתח חושף את שם המארח האמיתי ומסמן מארחים מילוליים IP, שזה בדיוק המידע שאתה רוצה לפני שאתה סומך על קישור כתבתי יותר על הרכבת סוג זה של ערכת בדיקה ב מדריך כלים לניפוי באגים ב-API.
כיצד ניתוח קשור לקידוד ו-slugs?
מנתח URL הוא פינה אחת במשפחה קטנה של כלי קישורים, ולדעת איזה מהם אתה צריך חוסך זמן. פְּרִיסָה קורא כתובת URL קיימת ומפרקת אותה. קִדוּד עושה את הכיוון ההפוך ברמת התווים - הפיכת רווחים ותווים מיוחדים לצורות המקודדות באחוזים שלהם כך שהם ישרדו בתוך כתובת URL, וחוזר חלילה. כאשר אתה צריך להטמיע בבטחה ערך במחרוזת שאילתה, או לפענח אחד שמעוות, כלומר מקודד/מפענח כתובת URL, והוא משתלב באופן טבעי עם המנתח: נתח כדי לראות את המבנה, מקודד כדי לתקן ערך שבור.
Slug דור היא עבודה שלישית, קשורה - לקחת תואר אנושי כמו "10 טיפים לבנייה מהירה יותר " והפיכתו לנקי 10-tips-for-faster-builds קטע נתיב. זה מה שה Slug מחולל ידיות, וזה מה שמייצר את המסודר path רכיב המנתח קורא מאוחר יותר בחזרה תחשוב על זה כעל צינור: slugify לבנות נתיבים טובים, לקודד כדי להפוך ערכים ל-URL בטוחים, לנתח כדי לבדוק את הקישור המוגמר. כל כלי עושה חלק אחד ממחזור החיים של כתובת האתר ועושה זאת בדפדפן.
מה לגבי כתובות IP ודומיינים בינלאומיים?
לא כל מארח מסודר example.com. כתובות URL מסוימות מצביעות על כתובות IP גולמיות, והמנתח מזהה את שתי הצורות. IPv4 פשוטו כמשמעו כמו http://192.168.1.10:3000/ בעל שם מארח של 192.168.1.10, והכלי מסמן אותו כ-IP ולא כדומיין - שימושי כשאתה מבקר קישור ורוצה לדעת באופן מיידי אם הוא מכוון לאתר בעל שם או לכתובת חשופה, שהיא אות נפוץ בקישורים חשודים. מילולי IPv6 עטופים בסוגריים מרובעים בכתובת URL, כמו ב http://[2001:db8::1]:8080/, והסוגריים הם חלק מהתחביר המארח, לא קישוט; המנתח מטפל בצורה בסוגריים בצורה נכונה במקום להיחנק מהנקודתיים, שאחרת היו נראים כמו מפרידי יציאות.
שמות דומיין בינלאומיים הם מקרה הקצה השני. מארח שנכתב בתווים שאינם ASCII - נניח דומיין עם אותיות מודגשות או לא לטיניות - מומר על ידי הדפדפן ' מנוע ה-URL שלו ל-Punycode שלו xn-- טופס לבקשה בפועל, כי DNS מדבר רק ASCII. לראות את המנורמל href במנתח מראה לך בדיוק מה הדפדפן יפתור, מה שמפתיע מדי פעם אנשים שציפו שדומיין ה-Unicode היפה שלהם יעבור ללא שינוי. עבור הדומיין ברמה העליונה, המנתח מחלץ את התווית הסופית של מארח בעל שם, אז shop.example.co.uk מדווח TLD של uk. זהו כלל פשוט בכוונה - הוא לא מנסה לבטל את הבחירה של סיומות מרובות חלקים כמו .co.uk לתוך תחום שניתן לרישום, כי לעשות את זה כמו שצריך דורש את רשימת הסיומות הציבורית, שהיא מערך נתונים נע גדול לבדיקה מהירה התווית האחרונה היא האות השימושי, ולכל דבר קפדני יותר היית מגיע לספרייה ייעודית.
דוגמה עובדת קושרת את זה ביחד תגיד שספק תשלומים ממשיך לדחות את כתובת האתר שלך להחזרה נרשמת https://app.example.com/checkout/return אבל הבקשה הכושלת מראה https://app.example.com:443/checkout/return/. נתח את שניהם. המנתח מראה שלראשון יש מארח app.example.com (יציאת ברירת מחדל, ללא קו נטוי נגרר בנתיב) ולשני יש מארח app.example.com מדי - אבל דרכו היא /checkout/return/ עם קו נטוי נגרר, והיציאה שלו נכתבה במפורש כ :443. שני הבדלים שהעין מחליקה מעליהם, שניהם קטלניים לבדיקת התאמה מדויקת. ברגע שאתה יכול לראות אותם כרכיבים מסומנים נפרדים, התיקון ברור: נרמל את החתך הנגרר ושחרר את היציאה המפורשת המיותרת.
טעויות נפוצות בעת קריאת כתובות אתרים
השגיאות החוזרות ראויות למתן שמות. בלבול בין הפרגמנט לנתיב או לשאילתה - הכל אחרי # האם הפרגמנט, הוא מטופל כולו על ידי הדפדפן ולעולם לא נשלח לשרת, אז פרמטר ששמת אחריו # לא יגיע לקצה האחורי שלך. בהנחה שיציאה חסרה פירושה שאין יציאה - יציאה שהושמטה פירושה הסכימה ברירת מחדל (443 עבור https, 80 עבור http), שהמנתח מבהיר כדי שתדע באיזו יציאה בקשה באמת תפגע.
התעלמות מקידוד כפול - אם ערך נראה כמו %2520 במקום %20, הוא קודד פעמיים; לנתח אותו, ואם הערך המפוענח עדיין מכיל רצף אחוז, לפענח שוב. אמון בטקסט הגלוי של קישור - הטקסט שאתה רואה והממשי href יכול להיות שונה לחלוטין, וזה כל המנגנון מאחורי פישינג; ניתוח חושף את מארח היעד האמיתי. ו התייחסות למפתחות שאילתה חוזרים ככפולים לביטול - לעתים קרובות הם מערכים משמעותיים, והורדתם מאבדת נתונים.
שאלות נפוצות
מהם החלקים של כתובת URL?
לכתובת אתר יש סכמה (HTTPS), אישורים אופציונליים (user:pass@), מארח (example.com) עם יציאה אופציונלית, נתיב (/blog/post), מחרוזת שאילתה אופציונלית (?id=42) וקטע אופציונלי (#section). מנתח זה מפריד ומתייג כל אחד מהם.
איך אני מנתח מחרוזת שאילתה?
הדבק את כתובת האתר המלאה וקרא את טבלת השאילתות, או הדבק רק את מחרוזת השאילתה בפני עצמה המנתח מפצל אותה על אמפרסנדס, מפענח קידוד אחוזים ומפרט כל זוג מפתח-ערך לפי הסדר מפתחות חוזרים כגון tag=a&tag=b נשמרים כשורות נפרדות.
מה ההבדל בין שם מארח, מארח ומקור?
Hostname הוא רק הדומיין או ה-IP (example.com). Host מוסיף את היציאה כאשר אחד קיים (example.com:8443). Origin הוא הסכימה פלוס מארח (https://example.com:8443) וזה מה שדפדפנים משתמשים לבדיקת אבטחה באותו מקור.
באיזו יציאה משתמשים כאשר לכתובת אתר אין מספר יציאה?
התוכנית מחליטה. ברירת המחדל של HTTPS היא 443, HTTP עד 80, SSH ל-22 ו-FTP ל-21. מנתח זה מציג את היציאה האפקטיבית ומסמן אותה כברירת מחדל, כך שאתה יודע באיזו יציאה בקשה תשתמש בפועל.
האם המנתח מפענח תווים מקודדים באחוזים?
כן, עבור ערכי שאילתה פרמטר כמו name=John% 20Doe מוצג מפוענח כ "John Doe" בטבלה מחרוזת החיפוש הגולמית מוצגת גם ללא נגיעה כך שתוכל להשוות בין הטפסים המקודדים והמפענחים.
האם אני יכול לנתח כתובת URL מבלי להקליד את חלק ה-HTTPS?
כן. אם אתה מדביק מארח חשוף או נתיב כגון example.com/pricing, המנתח מעמיד את https:// באופן אוטומטי ומציין שהוא קיבל את הסכימה. הדבק סכמה במפורש, כגון http:// או ftp://, כדי לעקוף את ההנחה הזו.
מדוע כתובת האתר שלי לא מצליחה לנתח?
בדרך כלל המארח חסר או פגום, הסכימה נכתבת בצורה שגויה, או שהמחרוזת מכילה תווים שאינם חוקיים בכתובת URL ואינם מקודדים באחוזים. בדוק אם יש רווחים, סוגריים לא נמלטו או לוכסן חסר לאחר התוכנית.
האם זה בטוח להדביק כתובות אתרים עם אסימונים או מזהי הפעלה?
כן. הניתוח פועל כולו בדפדפן שלך באמצעות מנוע ה-URL המקורי שלו. הקישור לעולם לא נשלח לשרת, לעולם לא נרשם, ולעולם לא מאוחסן, כך שכתובות אתרים המכילות אסימוני גישה, מפתחות API או שמות מארח פנימיים יישארו במכשיר שלך.
