ビデオと字幕 · ダイレクト メディア ダウンローダー
URL の構造: ページ アドレスがダウンロード可能なファイル アドレスではない理由
· 背景
URL ダウンロード Web の基本
すべての URL には同じ部分がありますが、ダウンロード可能なファイルを指しているのは一部だけです。この投稿では、スキーム、ホスト、パス、クエリ、フラグメントを分類し、ダウンローダーにリンクを貼り付ける前にリンクを読み取る方法を示します。
アドレス バーからのリンクでは何もダウンロードされませんでした — ページが存在する場所とファイルが存在する場所の間の混乱
ブラウザのアドレス バーには、通常、スタンドアロンのメディア応答ではなく、表示されているドキュメントの名前が表示されます。これをコピーすると位置が正確に保存されますが、その位置はプレーヤー アプリケーションによって表示されるバイトではなく、プレーヤー アプリケーションを表す場合があります。
ダウンロード可能なファイルのアドレスは、応答本文が目的のファイルである HTTP リソースです。 URL の出現によりその関係が示唆されることもありますが、連絡と応答の証拠がなければ関係を確立することはできません。したがって、最初の質問は「これはビデオのように見えますか?」ではありません。しかし、「出版社は、この正確なアドレスが表すリソースは何だと言いましたか?」まず、そのコピーされたアドレスがその中のどこかに見慣れた単語が出現するかどうかではなく、発行者がどのリソースを表現することを意図しているかを尋ねることから始めます。
スキームとホスト — https、ドメイン、およびホストがツールに接続する前に通知される部分である理由
`https://cdn.example:8443/archive/cut.mp4` では、HTTPS がスキーム、cdn.example がホスト名、8443 が明示的なポートです。オリジンはこれらのコンポーネントを組み合わせます。
ダイレクト メディア ダウンローダーは HTTPS のみを受け入れ、接続する前に正規化されたホスト名を通知します。難読化されたアドレス形式を含む、ホストおよび既知のプライベートまたは内部の宛先の前に埋め込まれた資格情報を拒否します。デフォルト以外のポートを明示的に指定すると別のサービスを識別できるため、UI アナウンスでホスト名が強調表示されるからといって頭の中で省略しないでください。明示的なポートはオリジンの一部のままであり、短いアナウンスでホスト名が強調されている場合でも、個別のサービスを識別する場合があります。
パス — フォルダーと最後のセグメント。通常、ファイル名と拡張子が表示されます。
パスは権限の後に始まり、スラッシュで区切られます。その最後のセグメントは多くの場合ファイル名に似ており、Content-Disposition がより良い提案を提供しない場合に ToolAcre が使用できます。
「多くの場合」は証拠ではありません。 `/watch/abc`、`/download/42`、および `/asset.mp4` はサーバー定義のルートです。ホストの動作に応じて、HTML、メディア、エラー、またはリダイレクトを返すことができます。パーセントエンコードされた文字は、デコード後に表示されるパスを変更することもできるため、ブラウザの解析されたビューは、カジュアルな文字列分割よりも安全に検査できます。パーセント エンコーディングにより、デコード後に表示される最終セグメントが異なる可能性があります。これも、スラッシュ分割の代わりに構造化解析を使用するもう 1 つの理由です。
クエリとフラグメント — パラメータ、トークン、アンカー、および ?v=ID クエリがビデオ ファイルを指さない理由
クエリは疑問符で始まり、リソースの選択、署名付きリンクの承認、または分析の実行を行うことができます。フラグメントは `#` で始まり、通常は HTTP リクエストで送信されるのではなく、クライアント側のドキュメントの状態を選択します。
`v=ID` などのパラメータは通常、ページの状態を識別します。それ自体は、応答がビデオ ファイルであることを意味するものではありません。 ToolAcre は、正規化中に追跡値の保守的なリストを削除しながら、耐荷重シグネチャを保持します。フラグメントは、ナビゲーション後のページの表示内容に依然として影響を与える可能性があるため、アドレス バーのコピーでは、サーバーの応答とは関係のないインターフェイスの状態が保持される場合があります。フラグメントは、サーバーに送信されたリクエストに存在しないにもかかわらず、ナビゲーション後にクライアント側のページ状態を変更する可能性があります。
可能性のある直接ファイル リンクを特定する方法 — 拡張子、プレーヤー ページなし、ページではなくファイルを提供するホスト
可能性の高い直接リンクには、予想されるパブリック ホストと、ファイルの発行者によって提供されたパスが含まれています。馴染みのある拡張子が手がかりであり、公式のダウンロード指示は、コピーされたプレーヤーのアドレスよりも強力なコンテキストです。
リンクがヘッダーを要求できることを確認します。メディア Content-Type は仮説をサポートしますが、`text/html` は警告を促します。応答にはまだ誤ったラベルが付けられている可能性があるため、ダウンロードと再生の成功は後の観察に残ります。発行者自身のページにあるダウンロード ボタンは、再生のみを目的として発行されたリバース エンジニアリング リクエストよりも、意図された取得を示す強力な証拠となります。発行者からの公式ダウンロード手順は、保護された再生中にのみ観察されるアセットのリバース エンジニアリングよりも強力なコンテキストを提供します。
作業例: 5 つのリンク形状 (CDN ファイル、短縮リンク、動画再生ページ、署名付き URL、フラグメントを含むページ) の分析
5 つの形状を比較します。 `.mp4` で終わる CDN パス。リダイレクトする短いリンク。 ID クエリを含む視聴ページ。署名と有効期限付きのストレージ パス。そして文書の断片。
1 つ目はファイルのように見え、2 つ目は最終ホストを隠し、3 つ目はページのように見え、4 つ目は一時的にのみ有効であり、5 つ目のフラグメントは送信されません。実際の HTTP 応答のみが到達可能性とラベルを決定します。短縮子は、推測ではなく、承認された監視可能なリクエストを通じて拡張される必要があります。そのブランドは、最終的なストレージの起源について決定的なものを何も伝えません。ショートナーのブランドだけでは最終的なストレージ オペレーターを特定できないため、許可された監視可能なリクエストを通じてのみショートナーを拡張します。
これでカバーされないこと — URL だけではファイルの存在やファイルの実際のタイプを証明できません
URL 解析では、存在、コンテンツ タイプ、長さ、承認、安全性、または法的許可を証明することはできません。また、リクエストを発行せずにリダイレクト先を予測することもできません。
ローカルの安全性の結果は、最初の宛先がスキームとホスト ポリシーに合格したことを意味します。これは、サーバーが再生可能なメディアを提供するという決定としてではなく、アプリケーションがネットワーク制御を提供するための許可として扱います。 DNS の動作と将来のリダイレクトには追加の境界が残るため、厳格な許可リストを持つ組織には、このクライアント側パーサーを超えたネットワーク制御が必要です。厳格な組織は、後の解決またはリダイレクト動作がホワイトリストを満たす必要がある場合、このパーサーを DNS および出力制御と組み合わせる必要があります。
要点: リンクを貼り付ける前に読んでください — ダイレクト メディア ダウンローダーの URL チェックがどのように同じ読み取りを行うか
貼り付ける前にレイヤー内のアドレスを読み取ります: プロトコル、ホスト名、ポート、パス、クエリ、およびフラグメント。署名の保存とは区別してクリーンアップを追跡し続け、公開されている文字列から権利を推測しないでください。
ダイレクト メディア ダウンローダーは、その構造読み取りをローカルに適用し、アクションを待ちます。オプションの HEAD リクエストとそれに続く GET は、構文だけでは解決できないさまざまな質問に答えます。この階層化された読み取りにより、正規の配信システムに必要な有用な署名付きクエリ情報が保持されながら、誤検知と誤った保証の両方が防止されます。この階層化された方法により、正当な署名付きパラメータが保存され、視覚的に見慣れていることが承認や存在と誤解されるのを防ぎます。