私はビデオアプリケーションを作成し、AWS S3にファイルを保存しています。https://***.amazonaws.com/***のようなデフォルトのURLを使用していますが、CloudFrontを使用することに決めました。 。AWS CloudFrontファイルをロードするときに403（禁止）を取得する
CFを使用して、このURLを使用して403 (Forbidden)を入手し続けます。https://***.cloudfront.net/***私は何かが欠けていたか？
私のバケットを指しているCloudFrontからコンテンツを読み込むまで、すべてうまく動作します。
解決方法はありますか？
入っているReferer:ヘッダーを検査するバケットポリシーを使用してS3コンテンツへのアクセスを制限する場合、CloudFrontを「outsmart」するためのカスタム設定を少し行う必要があります。
CloudFrontは正常に動作するように設計されていることを理解することが重要です。 「正常に動作する」とは、CloudFrontが、元のサーバーが返すものとは異なる応答を返さないように設計されていることを意味します。それが重要な要素であると私は確信しています。
のは、私はCloudFrontの背後にあるWebサーバ（ないS3）を持っているとしましょう、と私のウェブサイトは、それがReferer:ヘッダーの検査に基づいて異なるコンテンツを返すように設計された...または任意の他のHTTPリクエストヘッダ、User-Agent:のようなものです例えば。お使いのブラウザによっては、別のコンテンツを返す可能性があります。 CloudFrontはこれをどのように知っているので、あるページの間違ったバージョンをユーザーに提供することは避けられますか？
答えは、わかりません。これはわかりません。だから、CloudFrontのソリューションは、ほとんどのリクエストヘッダーを私のサーバーにまったく転送することではありません。私のWebサーバーが見ることができない、それに反応することができないので、私が返すコンテンツは、私が受け取っていないヘッダーに基づいて変化することはありません。 Webキャッシュには、特定のページの間違ったキャッシュされたコンテンツを返さないようにする義務があります。
「しかし待ってください。 「私のサイトは、応答する方法を決定するために、特定のヘッダーの値に依存しています。代わりに、単に要求されたパスに基づいて自分のページをキャッシュする
、私はあなたにもReferer:またはUser-Agent:または他のいくつかのヘッダーの1つ送られたように転送する必要があります。右、それは私たちがこのCloudFrontのを伝える必要があります...理にかなっていますブラウザによって、と同じパスだけでなく、私に転送する余分なヘッダーと同じ値を含む他の要求に使用する応答をキャッシュします。
しかし、元のサーバーがS3の場合、CloudFrontは、静的コンテンツが変化する可能性が低いため、ほとんどの要求ヘッダーの転送をサポートしていません。これらのヘッダーは複数の同一の応答を不必要にキャッシュするだけです。
解決策は、S3を起点としていることをCloudFrontに知らせることではありません。代わりに、 "カスタム"オリジンを使用するようにディストリビューションを設定し、オリジンサーバのホスト名として使用するバケットのホスト名を与えます。
Referer:ヘッダーを発信元に転送するようCloudFrontを設定すると、そのヘッダーに基づく要求を拒否/許可するS3バケットポリシーが期待通りに機能します。
まあ、ほぼ期待通りです。キャッシュされたページは、パス+参照ページに基づいてキャッシュされるので、キャッシュヒット率はいくらか低下します。S3オブジェクトはサイトの複数のページから参照され、CloudFrontは一意の要求ごとにコピーをキャッシュします。それは限界のように思えますが、実際には適切なキャッシュ動作の成果物に過ぎません。バックエンドに転送されるものはほとんどすべて、その特定の応答が将来の要求に対応できるかどうかを判断するために使用されなければなりません。
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeadersを参照して、CloudFrontが特定のヘッダーをホワイトリストに登録してオリジンサーバーに送信するように設定してください。
重要：必要なヘッダーは転送しないでください。これにより、すべての異種リクエストによってヒット率がさらに低下するためです。特にカスタム原点のバックエンドとしてS3を使用している場合は、Host:ヘッダーを転送しないでください。これは、おそらく期待通りには行かないためです。ここでReferer:ヘッダーを選択し、テストします。 S3はヘッダーを見てそれに応じて反応し始めるはずです。
バケットポリシーをテスト用に削除しても、無効化リクエストを送信してキャッシュをフラッシュしない限り、CloudFrontはキャッシュされたエラーページの配信を続けていました。約15分かけて行われる。実験の際に行う最も簡単なことは、新しい構成で新しいCloudFrontディストリビューションを作成することです。なぜなら、ディストリビューション自体には料金がかからないからです。
CloudFrontからの応答ヘッダーを表示するときは、X-Cache:（ヒット/ミス）とAge:（この特定のページがキャッシュされた時間）の応答に注意してください。これらはトラブルシューティングにも役立ちます。
更新：@alexjsは重要な観察をした：代わりにバケットポリシーを使用してこれを行うと、分析のためにS3にReferer:ヘッダを転送するの - によって変動する程度まで、あなたのキャッシュ比率を傷つけます参照ページ上のリソースの広がり - 新しいAWS Webアプリケーションファイアウォールサービスを使用できます。これにより、CloudFrontへの着信要求に対するフィルタリングルールを適用し、string matching in request headersに基づいて要求を許可またはブロックすることができます。
これを行うには、S3のソースとしてS3にディストリビューションを接続する必要があります（上記のソリューションで提案したものとは異なり、通常の設定で、 "カスタム"の起点） CloudFrontがS3へのバックエンド要求を認証する機能（バケツの内容は悪意のある俳優がS3から直接要求した場合、直接アクセスできない）
このオプションの詳細については、https://www.alexjs.eu/preventing-hotlinking-using-cloudfront-waf-and-referer-checking/を参照してください。
また、単純なものかもしれません。最初にファイルをS3バケットにアップロードすると、そのバケット内の他のファイルが公開されていても、バケット自体が公開されていても、非公開です。
これをAWS Consoleで変更するには、公開するフォルダ（アップロードしたフォルダ）の横にあるチェックボックスをオンにし、メニューから[公開する]を選択します。
そのフォルダ（および任意のサブフォルダ）内のファイルは公開され、S3からファイルを提供することができます。 AWS CLIの場合
は、そのように、あなたのコマンドに「--acl公開読み」オプションを追加します。あなたが与えられていないaws s3 cp index.html s3://your.remote.bucket --acl public-read
私たちはずっと上に行くために。事前に署名されたURLを使用していますか？バケットポリシーは、特定のリクエストパラメータに基づいてリクエストを拒否しますか？ –
@ Michael-sqlbot私は、署名済みのURLを使用していません。これは標準の設定です。私が設定したポリシーは、ファイルをロードするために自分のURLだけを受け入れることでした。 – Shina
だから、バケツポリシーに '" Condition "：{ " StringLike "：{" aws：Referer "：[" http://www.example.com/* "]} }のバケツポリシーを使用していますか？ –