ファイルストレージサイトのダウンロードリンクに長い一意のIDがあるのはなぜですか？
ファイルストレージサイトを作成していますが、ダウンロードリンクの形式は次のようにします。
https://www.domain.com/[id]/[file name] //id would just be 1, 2, 3 etc.
Dropboxと他の多くのIDは、IDが長い/ハッシュ化されていることを除いて、同様に持っています：
https://www.dropbox.com/s/23d3kaz4adw9deq/anyfile.txt
それをそのように持っていることの背後にある（セキュリティ）理由はありますか？
私は多分彼らがそのようにそれをするので、人々がidを1だけインクリメントし、出くわすすべてをダウンロードするだけで、不必要に多くの帯域幅を失うことになるのではないかと考えていました。しかし、そうではありません。IDとファイル名の両方が一致する必要があり、ファイル名が簡単に推測できないためです。
それをそのように持っていることの背後にある（セキュリティ）理由がありますか？
はい-タイプの セキュリティによるあいまいさ -URLは認証なしで利用できるため、ファイルは実際には安全ではありませんが、推測できないため、かなりプライベートになります。さらに多くの情報（ブラウザの履歴ログなど）や、この場合は実行不可能なような総当りの力が必要になります。
私は多分彼らがそのようにそれをするので、人々がidを1だけインクリメントし、出くわすすべてをダウンロードするだけで、不必要に多くの帯域幅を失うことになるのではないかと考えていました。しかし、そうではありません。IDとファイル名の両方が一致する必要があり、ファイル名が簡単に推測できないためです。
彼らではないですか？ readme.txt、password.txt、untitled.bmp、CV.docなど.
一般的な単語リスト は広く利用可能であり、一般的なファイル拡張子やさまざまなIDと組み合わせてブルートフォースプログラムに送り込んで、システムに攻撃を実行することができます。このため、URLに安全なランダムコンポーネントを含めることをお勧めします。
まあ、セキュリティ（適切な認証などの他の手段を介して達成できる）よりも、問題は、フロントエンドが複数ある場合、シリアル番号やスケールなどを簡単に実装できないことです。サービスが地理的に分散している場合（災害復旧または場所の問題のみ）。
何千ものストレージサーバーがあり、ファイルを保存しているDropboxのようなサービスを想像してください。現在のファイルのインデックスを保持するのは誰ですか。同じアカウント内であっても、クライアントが同時にファイルをアップロードすることで同じ問題が発生します。
これを回避する方法は、衝突の可能性が無視できるようにファイルのURIを作成することです。そのため、SQLサーバーなどのシステムは、自動インクリメントのプライマリインデックスと、GUIDに基づく一意のIDの両方を常にサポートしてきました。データベースに取り組んだ経験のある人は、単一のDBサーバーが確実に存在することがわかっている場合を除き、ほとんどの場合GUIDを使用しました。
拡張がはるかに簡単なため、URLをアクセスキーとして使用しています。ファイルを検索してから、マスターデータベースにアクセスして、別のシークレット（たとえば、セッションCookie）に基づいてファイルへのアクセスが実際に許可されているかどうかを確認する代わりに、URLが長く、十分にランダムであることがわかっている場合、別の認証サービスに問い合わせる必要なく、アクセスを許可されている必要があります。
不利な点は、特にファイルがキャッシュされている場合（キャッシュが期限切れになるまで待つ必要がある場合）、ファイルへのアクセスを取り消すのは簡単ではなく、URLはユーザーのアクセスが容易であるため、パスワード/セッションCookieよりも簡単にリークする可能性があることです。たとえば、履歴、およびエンタープライズHTTPSインターセプトプロキシのログ。