マッピング タイルをプライベート S3 バケットに保存したいと考えています。各タイルには独自の URL があり、タイルの各セットには数 GB のタイルが含まれる可能性があります。
次に、フロント エンド マッピング クライアント (リーフレットなど) を介してこれらのタイルを視覚化します。このクライアントは、タイルの個々の URL を使用して、必要に応じてタイルをプルします。
バケットはプライベートであるため、各タイル リクエストを認証する必要がありますが、このアプリケーションではパフォーマンスが非常に重要です。
heroku を使用してサイトをホストしたい場合、S3 からタイルをリクエストする前に heroku を介して URL をプロキシし、署名を取得するか、heroku を介してタイル自体をプロキシする方がよいでしょうか?
他のオプションはありますか？
理想的には、認証トランザクションを最小限に抑えるために、S3 バケットへのアクセスが許可されているサーバーを介してリクエストをプロキシする必要があると思います。
Heroku 上にあるかどうかに関係なく、プロキシ サーバーがエンド ユーザーのアクセスを認証し、必要なセキュリティ ポリシーに従ってそのセッションを維持できる限り、問題はありません。
Cesium は Imagery と Terrain のプロキシをサポートしているため、サーバーで CesiumProxy を構成するだけで準備完了です。
S3 のコンテンツが非公開の場合、バケット ポリシーでプロキシが IP アドレスに基づく認証なしでコンテンツにアクセスすることを許可しない限り、何らかの方法でダウンロードを承認する必要があります。その場合でも、プロキシは、(おそらく) Cookie を介してユーザーが承認されていることを確認する必要があります。これは、セッション データベースのルックアップを意味する場合があります。
署名付き URL の生成は、計算上特にコストのかかるプロセスではなく、(私がときどき遭遇する印象とは対照的に) 署名プロセスは完全にサーバー上で行われます。署名付き URL を生成するときに発生する S3 との実際のやり取りはありません。
本当の正解は一つではありません。私は両方のアプローチとそれらの組み合わせを使用します。アプリケーションで URL に署名し、データベースで署名し (URL に署名する MySQL ストアド関数を作成しました)、ユーザーのセッション Cookie を読み取る別のアプリ サーバーへのリンクを提供します。承認された場合は、署名付き URL を生成し、302 リダイレクトを返し、事前に署名された URL リクエストを S3 にプロキシするプロキシ サーバーへのリンクを提供します (リアルタイムのログ記録と、独自のドメイン名と SSL 証明書の使用を許可するため) )...これらすべてのアプローチおよびその他のアプローチには有効なユースケースがあります。