アップロード中にローカルに保存したくないという矛盾した目標がありますが、サムネイルを作成するために不必要に再度ダウンロードしたいという目標もあります。技術的な優れた賞を受賞したい場合は、ファイルアップロードリクエストの本文をローカルの一時ファイルと S3 に同時にストリーミングできます。または、他の業界と同じように、ローカルの一時ファイルに保存してからサムネイル化し、すべてのサイズを S3 にアップロードすることもできます。これらのアプローチのいずれかにより、サムネイルを作成するために S3 からすぐにダウンロードする必要がなくなります。
それが本当に画像であることをどのように正確に検証するつもりですか? ファイル データの最初のチャンクを調べて、ファイル タイプのマジック ナンバーを検証することはできますが、それによってウォーム ファジーが得られる場合もありますが、最終的には信頼できないユーザー データになります。想定される画像ファイルの後半部分はウイルス コードである可能性があり、それはContent-Type
ヘッダーで簡単に偽造できます。セキュリティ上の懸念は、防御しようとしている特定の脅威ではなく、主にFUDによって引き起こされているようです。ユーザーがアップロードしたデータを取得せず、実行可能としてマークし、サーバー上でルートとして実行しない限り、画像以外のデータは破損し、ブラウザで正しくレンダリングできません (および/またはエラーで終了するか、極端な場合にはクラッシュする可能性があります)。
検証に関しては、サムネイルを作成してみることができます。できない場合は、有効な画像ではなく、削除してください。この方法でいいですか?
ほとんどの場合、はい。サムネラーが画像を処理できない場合がありますが、サムネラーが完全ではなく、一部の画像が部分的に破損しているため、ブラウザーは処理できます。たとえば、Web ブラウザーで適切にレンダリングおよびアニメーション化されるアニメーション GIF をいくつか見つけましたが、それらを処理しようとすると、graphicsmagick がクラッシュします。これらの 0.01% のエッジ ケースについて何かできることがあるかどうかはわかりません。
アップロード部分については、ユーザーに応答を送信してから、サムネイルの作成と S3 への保存を続行できますか?
はい、アップロードが成功したことをユーザーが認識できるようにするため、一般的にはこれが最善の方法です。通常、画像処理は「作業キュー」モデルとして設計されています。このモデルでは、実行する作業があることを記録してから続行し、別のプロセスまたは複数のプロセスが作業をキューから取り出して完了します。