基本的なHTTPパスワード認証はCDNアクセスに干渉できますか？
私はこの質問をするために最善を尽くしています。このタスクのMIAである別のチームをカバーするために、ここでドメインを横断します。質問が愚かに聞こえる場合は私を案内してください。
Apacheサーバー上のVHostを介してホストされているとされるWebサイトを扱っています。したがって、blah.oursite.comにアクセスすると、静的アセットの多くは、S3バケットを指すCDNからリダイレクト/プロキシ/何かを介して実際に送信されます。
したがって、この粗雑な視覚バージョンを作成しようとすると：ユーザー> VHostサイト>リダイレクト/プロキシをCDN> S3
この場合のVHostのサイトとアセット（特定のサブドメインblah）は、.htaccessで制御される基本HTTPパスワード認証と思われるものによって保護されています。したがって、blah.oursite.comにアクセスすると、ブラウザにユーザー名とパスワードを要求するポップアップが表示されます。これは仕様です。
私たちが見ているのは、外部CDNでホストされているいくつかの静的アセットがblahサブドメインにロードできないことです。 www.oursite.comをロードすると、すべてのアセットが問題なくロードされます。したがって、この特定のドメインの初心者としての主要な理論の1つは、.htaccess資格情報保護がblahサブドメインのCDNされたコンテンツにアクセスする能力を妨害しているということです。
それは理にかなっていますか？それは可能ですか？この理論をテストするために（Apacheインスタンスを管理するチームがどのような構成を設定しているかわからない）、または問題をトラブルシューティングするためにどのテクニックを使用できますか？他のチームからの協力がなければ、運が悪いのでしょうか？
User > VHost site > redirect/proxyの間のステップで何が起こっているかについて詳しく説明したいと思いますが、残念ながら私のチームはプロセスのそれらのステップを所有しておらず、それらを所有するチームはこれを解決する上で私たちとうまく遊んでいません。問題が何であるかを見つけ、解決する方法を見つけるのに役立つガイドまたはヒントは、非常に役立ちます。サーバー管理の経験がありません。
弊社のウェブサイトのいずれかのステージングコピーを設定する際に、最近このタイプの問題に対処しました。適切にセットアップされていることを確認するためにcdnを介してアセットをロードする必要がありましたが、cdnは、説明したように.htaccess基本パスワード認証によって拒否されました。
これを回避するために、Apacheの SetEnvIF Directive を使用しました。
CDNリクエストからのHTTPリクエストヘッダーを照合し、環境変数を設定してから、基本的なパスワード保護によりその環境変数を使用したトラフィックを許可できます。
CDNのUser-Agentに基づいてこれを行うには、.htaccessファイル（Apache 2.4用）は次のようになります。
SetEnvIf User-Agent ^cdnUserAgentToMatch$ cdn
AuthType Basic
AuthName "Test Site"
AuthUserFile "/path/to/passwd"
Require valid-user
Require env cdn
ErrorDocument 401 "Authorization Required"
これにより、有効なユーザーまたはcdn環境変数を使用した要求にアクセスできます。注：デフォルトでは、 Require Directives は<RequireAny>タグにラップされていると評価されます。そのため、2つのオプションがありますが、1つを含める必要はありません。
User-Agentはスプーフィングされる可能性があるため、環境変数を設定するときに、要求元のIPアドレスと照合するのがおそらく最善です。または、さらに良いことに、一部のCDNでは、次のように、キーを挿入して確認できるカスタムHTTPヘッダーを設定できます。
SetEvnIf CustomHeader ^5tfasdoqu7891435$ cdn
ロードする静的リソースに絶対に保護する必要があるものが含まれていない限り、プロキシを介してロードする必要はありません。 CDNを使用するポイントは、コンテンツをエンドユーザーの近くに移動し、多数のサーバーに配信することで、ページの読み込み時間を増やし、メインサーバーに送信されるコールを減らすことです。
ここで何が起きているのが理想的かは、サイト自体が選択した認証メカニズムの背後にあることですが（これはユーザー次第です）、CDNの静的リソースはそうではありません。 BasicAuthで保護されたサイトに配置すると、保護されていないサイトにロードするのと変わりません。
現在、アドレス指定スキームに応じて、サイトでhttpsが使用されている場合、これは静的リソースのロードで元に戻すことができるものです、特にほとんどのブラウザがhttpsではなく標準http接続を介して静的リソースにアクセスしている場合セキュリティ上の理由から、httpsで保護されたサイトにhttpsで保護されていないコンテンツをロードする。
また、あなたのサイトはあなたのサイトがvHostでホストされていると述べ、静的コンテンツがプロキシまたはCDNからの類似物を介して取り込まれると仮定しました。ここで、これはベストプラクティスではなく、実際にCDNを使用する目的に反していることを指摘しますが、この方法で静的コンテンツとして追加され、サーバー上のhtmlは、HTMLページがロードされると、エンドブラウザーによってCDNから直接取得されます。
このような問題が発生した場合、私が見つけた最も一般的な原因は、httpsで保護されたサイトからhttpリソースにアクセスするか、承認済みサイトリストにないサイトでリファラー制限（ホットリンク保護）でCDNの静的リソースを使用しようとしたことです。
Https問題の場合、サイトにプロトコルとしてhttps：//があるかどうかを確認する必要があるだけでなく、HTMLコードをチェックして静的リソースが読み込まれているかどうかを確認するだけで簡単に識別できますhttps：//アドレスまたはhttp：//アドレス。
これがリファラー保護の問題である場合、これを特定するのは少し難しくなります。最も簡単な方法は、ブラウザでサイトをロードし、Google Chrome開発者ツールを開いて、下部のコンソールを見ることです。リソースのロードで問題が発生した場合は、HTTPステータスコードおよびロードに失敗した実際のファイルとともにここに表示されます。