午後を 1 度、問題ないように見える URL に負けました。 OAuth コールバックが失敗し続け、リダイレクト URI がプロバイダーに登録されたものと一致しましたが、ハンドシェイクが壊れた理由がわかりませんでした。 最終的にパーサーに貼り付けたときの答えは、パスの末尾にある場所で、他の場所では何もせず、さらに別の場所では、パスのスラッシュでした。 state ダブルエンコードされたパラメータなので %20 になっていました %2520。 人間の目には、2 つの URL は同じでした。 OAuth サーバーには異なる文字列があり、不一致を拒否するのは正しかった。
それがURLの問題です: それらは密度が高く、読み間違えやすく、物事を壊す詳細 - エンコードされたスラッシュ、迷走ポート、繰り返しクエリキー、パスを期待したフラグメント - は、まさに文字の壁に隠れているものです。 [Toolz.dev] (/) を構築し、デバッグ中にクエリ文字列を見つめるのに十分な時間を費やして、それを構築しました URL パーサー 私のために見つめることをするために。 リンクを貼り付け、すべてのコンポーネントをラベル付けし、すべてのクエリ パラメータをテーブルにデコードします。 このガイドでは、これらのコンポーネントとは何か、なぜ重要なのか、どのように使用するのかについて説明します。
tl;dr: URL はスキームで構成されています (
https)、オプションの資格情報 (user:pass@、ホスト (example.com) オプションのポート、パス (/blog/post)、クエリ文字列 (?id=42)、および断片 (#section. ザ・ URL パーサー ブラウザー独自の WhatWG URL エンジンを使用して、これらの部分にリンクを分割し、クエリを順序付けされたキー値テーブル (繰り返しキーを分けて保持) にデコードし、スキームの有効なポートを表示し、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 |
オプションの資格情報 : UserInfo で。 |
| ホスト名 | shop.example.co.uk |
ポートのないドメインまたは IP アドレス。 |
| ポート | 8443 |
オプション。 省略すると、スキームのデフォルトに戻ります。 |
| ホスト | shop.example.co.uk:8443 |
ポートが存在する場合のホスト名とポート。 |
| 原点 | https://shop.example.co.uk:8443 |
スキームとホスト - ブラウザがセキュリティに使用するユニット。 |
| パス | /catalog/shoes |
ホスト上のリソースの場所。 |
| 質問 | ?color=red&size=42 |
キー値のパラメータ ?。 |
| 断片 | #reviews |
クライアント側アンカー #、サーバーに送信されません。 |
パーサーは、これらすべてをコピー ボタンで独自の行として配置するため、モンスター URL からホスト名を手で抽出する必要はありません。 また、生の文字列が非表示にするいくつかのこともフラグを立てます。表示されているポートが明示的か、スキームのデフォルトか、またはホストが名前付きドメインか生の IP かのどちらかです。
ホスト名、ホスト、オリジンの違いは何ですか?
この3 人は絶えず人をつまずかせます 混乱は本物のバグを引き起こします - CORSの失敗、クッキーのスコーピングミス、リダイレクトの不一致 彼らは同義語ではありません The 何という URL 標準 ブラウザが実際に実装する定義であり、何がオリジンとしてカウントされるかについての議論を解決する場所です。
ホスト名 ドメインまたは IP だけですか: shop.example.co.uk。 ポートもスキームもありません。 DNS ルックアップに入れるものです。
ホスト ホスト名にポートを加えたものは、 ただし、URL にポートが存在する場合に限ります。 のため shop.example.co.uk:8443 ホストは shop.example.co.uk:8443。 平野の場合 https://shop.example.co.uk/ デフォルトのポート 443 は、書き込まれたものではなく暗黙の暗示がなされているため、ホストとホスト名は同じです。 「存在する場合にのみ」ルールは微妙であり、同じサイトに 2 つの異なるホストがあるように見える理由です。
原点 スキームプラスホスト: https://shop.example.co.uk:8443.これはブラウザが最も気にかけている1 つです なぜなら同一オリジンポリシー - ウェブセキュリティの基盤 - はホスト名ではなくオリジン同士を比較するからです 2 つのURLはスキーム hostname, の場合にのみオリジン同士を共有します あんど ポートオールマッチ。 http://example.com あんど https://example.com スキームが異なるため、起源が異なります。 https://example.com あんど https://example.com:8443 ホスト名が同じであっても、ポートが異なるため、発信元が異なります。 CORS エラーでフェッチが失敗している場合、通常、パーサーで 2 つの原点を並べて比較することが、不一致を見つける最も早い方法です。
クエリ文字列を解析するにはどうすればよいですか?
クエリ文字列は、日常的にほとんどの痛みが生きる場所です。これは、実際には構造化され、パーセント エンコードされた、平らでエスケープされていないブロブであるためです。 パーサーがあなたのためにそれを分割します: すべての後に ?、壊れている &、それぞれ key=value ペアをデコードして、元の順序で表にリストします。
ここでは 2 つの行動が重要です。 まずは、 デコード。 として記述されたパラメータ q=trail%20runner ワイヤ上に次のように表示されます。 trail runner 値の列では、 %20 パーセントエンコードされたスペースです。 生 search コンポーネント リストには文字列がまだ手付かずで表示されているため、エンコードされたフォームとデコードされたフォームを比較できます。私のように、二重エンコードが疑われる場合は非常に貴重です %2520 オーサのバグ。
2番目、 繰り返しキー。 URL は、同じキーを複数回以上正当に持つことができます。 ?tag=react&tag=typescript&tag=node.多くの素朴なパーサーはこれらを折りたたみ,最初または最後の値だけを保持し,静かにデータを失います.それは間違っています - 繰り返しキーとは,HTML フォームが複数選択フィールドを送信する方法と,多くの API が配列を表現する方法です.パーサーはあらゆる出現を順番に独自の行として保持するため,3 つのタグがすべて表示されます.クエリを JSON としてコピーすると,繰り返しキーは配列になります.これはコードが最も期待する形状です。
これを使うのに完全なURLさえ必要ありません クエリ文字列だけを貼り付けます - color=red&size=42 ー そしてツールはそれを自分で解析します Webhookのペイロードや 誰かが転送した追跡リンクを 理解するには私が知る限り最速の方法です。
URL パーサーをどのように使用しますか?
ツールは邪魔にならないように設計されています。 URLを単一の入力に貼り付けると、入力するとライブで解析されます。押すボタンはありません。サンプルリンクがプリロードされているため、完全な内訳がすぐに確認でき、クリアボタンでフィールドが空になります。
スキームを入力する必要はありません。 裸のホストを貼り付けます example.com/pricing そしてパーサーは先頭に立つ https:// 自動的に、その後、それが小さなメモでそうしたことを伝えるので、スキームがどこから来たのかについて混乱することはありません 明示的なスキームを貼り付けます - http://、 ftp://、 ssh:// - そして代わりにそれを尊重します。
出力には 4 つのゾーンがあります。 一番上にあるのは、 正規化された URL - canonical form the browser's engine produced, with a copy button, which is handy for catching suttle normalization differences. - の正規フォームブラウザ& #39; sエンジン、コピーボタンで、微妙な正規化の違いをキャッチするのに便利ですその下に、 コンポーネント 表、パーツごとに 1 つのラベル付きの行で、それぞれ独立してコピー可能です。 そしたら パス セグメント、インデックス付きチップに割り込まれているので、次のような深いパスです /api/v2/users/42/orders は一目で判読可能です。 最後に クエリ パラメータ テーブルをデコードして順序付け、「json としてコピー」アクションを使用すると、クエリ全体がクリーンなオブジェクトに変換されます。
すべてのブラウザーでネイティブ URL エンジンを使用して実行されます。 これは意図的な選択です。URL には日常的にアクセス トークン、セッション ID、署名済みパラメータ、および内部ホスト名が含まれており、そのどれもがサーバーに出荷されてから読み取られる必要はありません。 貼り付けてもデバイスから離れることはなく、ツールはオフラインで動作し続けます。 これは、ツールキット全体の背後にある同じプライバシー ファースト アプローチであり、これは、 Web 開発者ツールキット ガイド。
URL パーサーはいつアクセスできますか?
私自身の仕事で、いくつかの状況が何度も出てきます。 リダイレクトとコールバックのデバッグ 大きいのは、oauth フロー、支払い返却 URL、SSO ハンドシェイクです。これらはすべて、両方の URL を分解したときにのみ表示される小さな不一致で失敗します。 追跡リンクの監査 もう 1 つ: マーケティング URL は、多くの場合、基本ページに加えて、12 個の UTM および AD-Platform パラメーターであり、300 文字の文字列で目を細めて表にするよりも、それらを表として読み取ることができます。 リンクを読むのではなく、それらのリンクを構築している場合、 UTM ビルダー 同じワークフローの残りの半分です。
それならある API 作業 ークライアントが実際に送信したクエリパラメータを検査したり、エンドポイントがフィルターをどのように期待するかをリバースエンジニアリングしたりします。 と セキュリティーレビュー: メールやログにあるなじみのないリンクは、その部分を解析することでより安全に理解できます (これはどのホストを実行しますか? ほんと ポイントは?) をクリックするよりも、そのホスト名は IP ですか?) をポイントします。 パーサーは、真のホスト名を公開し、リンクを信頼する前に必要な情報である IP リテラル ホストにフラグを設定します。 この種の検査キットの組み立てについて詳しく書きました。 API デバッグ ツール ガイド。
解析はエンコーディングと slugs にどのように関係しますか?
URL パーサーは、リンク ツールの小さなファミリの 1 つのコーナーであり、必要なツールを知ることで時間を節約できます。 パージング 読みます 既存の URL を切り離して引き離します。 エンコーディング 文字レベルで逆の方向を行います - スペースと特殊文字をパーセントエンコードされた形式に変換して、URL 内に残るようにし、再び戻します。値をクエリ文字列に安全に埋め込む必要がある場合、またはマングルされている値をデコードする必要がある場合、つまり、 URL エンコーダ/デコーダ、自然にパーサーとペアリングします。解析して構造を確認し、エンコードして壊れた値を修正します。
Slug 生成 3 番目の関連する仕事です - " のような人間の称号を取得します。より高速なビルドとクォートのための 10 のヒント;そしてそれをクリーンに変えます 10-tips-for-faster-builds パス セグメント。 それが何だ Slug ジェネレーター ハンドルを握り、それがきちんとしたものを生み出すものです path パーサーが後で読み返すコンポーネント。 pipeline と考えてください。 slugify で良いパスを構築し、エンコードして値を URL セーフにし、解析して完成したリンクを検査します。各ツールは URL ライフサイクルの一部を実行し、ブラウザで実行します。
IP アドレスと国際化ドメインはどうですか?
すべてのホストがきちんとしたものであるとは限りません example.com。 一部の URL は生の IP アドレスを指し示し、パーサーは両方のフォームを認識します。 IPv4 リテラルのような http://192.168.1.10:3000/ のホスト名があります 192.168.1.10、およびツールは、ドメインではなくIPとしてフラグ - リンクを監査しているときに便利で、名前付きサイトをターゲットにするか、または不審なリンクで一般的な信号である裸のアドレスをターゲットにするかを即座に知りたい場合のように、URLでIPv6 リテラルを角括弧で包みます http://[2001:db8::1]:8080/、括弧は、装飾ではなくホスト構文の一部です。パーサーは、コロンで窒息する代わりに、そのかっこが付いた形式を正しく処理します。これは、ポート セパレータのように見えます。
国際化されたドメイン名はもう 1 つのエッジケースです。非 ASCII 文字で書かれたホスト (アクセント付きまたは非ラテン文字のドメインなど) は、browser's URL エンジンによって Punycode に変換されます xn-- DNS は ASCII のみを話すため、実際のリクエストのフォーム。 正規化されたものを見る href パーサーで、ブラウザーが何を解決するかを正確に示します。これは、かなりの Unicode ドメインが変更されずに移動することを期待していた人々を驚かせることがあります。 最上位ドメインの場合、パーサーは名前付きホストの最終ラベルを抽出します。 shop.example.co.uk TLD を報告する uk。 これは意図的に単純なルールです。次のような複数部分のサフィックスを解読しようとはしません .co.uk 適切に行うには、移動する大規模なデータセットである公開サフィックス リストが必要になるため、登録可能なドメインに入ります。 迅速な検査には、最後のラベルが便利な信号であり、より厳密なものについては、専用のライブラリにたどり着くことができます。
実例が結びついています。 支払いプロバイダーが返却 URL を拒否し続けるとします。 登録した https://app.example.com/checkout/return しかし、失敗したリクエストは https://app.example.com:443/checkout/return/。 両方を解析します。 パーサーは、最初のホストにホストがあることを示しています app.example.com (デフォルト ポート、パスに後続のスラッシュはありません) で、2 番目にホストがあります app.example.com あまりにも - しかし、その道は /checkout/return/ 末尾にスラッシュを付けて、そのポートは明示的に次のように書き込まれました。 :443。 2 つの違いは、目を完全に一致するチェックに致命的です。 ラベル付きの別のコンポーネントとしてそれらを確認できたら、修正は明らかです。後続のスラッシュを正規化し、冗長な明示的なポートをドロップします。
URL を読むときのよくある間違い
繰り返し発生するエラーは名前を付ける価値があります。 フラグメントとパスまたはクエリを混同する ーその後の全て # は、完全にブラウザーで処理され、サーバーに送信されることはないため、後で設定したパラメーター # バックエンドに到達しません。 ポートが欠落しているということは、ポートがないことを意味 - 省略されたポートはスキームを意味します デフォルト (HTTPS の場合は 443、HTTP の場合は 80)、パーサーが明示して、どのポートのリクエストが実際にヒットするかがわかります。
ダブルエンコーディングを無視する ー もし値が のように見えるなら %2520 代わりに %20、2 回エンコードされ、解析され、デコードされた値にパーセント シーケンスが含まれている場合は、再度デコードします。 リンクの表示テキストを信頼する ー目にするテキストと実際の href フィッシングの背後にあるメカニズム全体である完全に異なる場合があります。解析すると、実際の宛先ホストが明らかになります。 あんど 繰り返しクエリ キーを重複として処理して破棄する - 多くの場合、それらは意味のある配列であり、それらをドロップするとデータが失われます。
よくある質問
URL の部分は何ですか?
URL には、スキーム (https)、オプションの資格情報 (user:pass@)、オプションのポートを持つホスト (example.com)、パス (/blog/post)、オプションのクエリー文字列 (?id=42)、オプションのフラグメント (#section) があります。 このパーサーは、それぞれを分離してラベル付けします。
クエリ文字列を解析するにはどうすればよいですか?
完全な URL を貼り付けてクエリ テーブルを読み取るか、クエリ文字列だけを単独で貼り付けます。 パーサーはそれをアンパサンドで分割し、パーセントエンコードをデコードし、すべてのキーと値のペアを順番にリストします。 tag=a&tag=b などの繰り返しキーは、別の行として保持されます。
ホスト名、ホスト、オリジンの違いは何ですか?
ホスト名は、ドメインまたは IP (example.com) だけです。 ホストが存在する場合はポートを追加します (example.com:8443)。 原点はスキームプラスホスト (https://example.com:8443) と同じオリジンのセキュリティ チェックに使用するブラウザです。
URL にポート番号がない場合、どのポートが使用されますか?
スキームが決定します。 HTTPS のデフォルトは 443、HTTP は 80、SSH は 22、FTP は 21 です。 このパーサーは有効なポートを表示し、それをデフォルトとしてマークするため、リクエストが実際にどのポートを使用するかがわかります。
パーサーはパーセントエンコード文字をデコードしますか?
はい、クエリ値の場合。 NAME=John%20DOE のようなパラメーターは、表に "John Doe" としてデコードされて表示されます。 生の検索文字列もそのまま表示されるので、エンコードされたフォームとデコードされたフォームを比較できます。
https パーツを入力せずに URL を解析できますか?
はい。 example.com/pricing などの裸のホストまたはパスを貼り付けると、パーサーは自動的に https:// の前に付けて、スキームを想定したことを示します。 http:// や ftp:// などのスキームを明示的に貼り付けて、その仮定をオーバーライドします。
URL が解析できないのはなぜですか?
通常、ホストが見つからないか、不正な形式で作成されているか、スキームが正しく書き込まれていないか、または URL で違法でパーセント エンコードされていない文字列が含まれています。 スキームの後にスペース、エスケープされていないブラケット、またはスラッシュの欠落がないか確認してください。
トークンやセッション ID で URL を貼り付けても安全ですか?
はい。 ネイティブ URL エンジンを使用して、ブラウザーで完全に解析します。 リンクはサーバーに送信されず、ログも記録も保存もされないため、アクセス トークン、API キー、または内部ホスト名を含む URL はデバイスに残ります。
