TomcatにWebアプリケーションがあります。アプリは専用のApacheHTTPServerからコンテンツ（機密）にアクセスします。許可されていないユーザーがこのコンテンツにアクセスすることは望ましくありません。つまり、WebApp（Tomcat上）を介して認証されたユーザーのみがHttpServerコンテンツにアクセスできます。（ネットワークを保護するためにHTTPSを使用していますが、誰かがコンテンツの直接httpserver URLを取得した場合、コンテンツをダウンロードする可能性があります）。
Tomcatの同じWebアプリでコンテンツをホストすることを考えています。何か案は？
これを行う簡単で怠惰な方法は、Apacheサーバーへの各ヒットでHTTPリファラーがTomcatサーバーのアドレスであることを強制することです。そのページ：http ：//www.htaccess-guide.com/deny-visitors-by-referrer/
ただし、ハッカーがHTTPリファラーをスプーフィングするのは、それがあなたの保護スキームであると判断した場合、かなり簡単です。
努力の順に、2つのより複雑ですが安全な方法：
ユーザーがログインしていることを確認するJSPページなどをTomcatサーバーに書き込み、HTTPによってApacheからデータをフェッチしてから、データをエンドユーザーに出力します。これを行うことで、効果的に独自のリバースプロキシを作成しています。次に、Apacheサーバーをロックダウンして、TomcatサーバーのIPアドレス（および許可するその他の許可された/内部IP）にのみページを提供します。長所：それでもかなり迅速に実行できます。短所：Tomcatリソースを使用して他のサーバーから各ページを表示している場合、特にapacheサーバーが大量のバイトを処理する場合（たとえば、apacheが500 megファイルを処理する場合、スケーラビリティの問題が発生する可能性があります）あなたのTomcatスクリプトのメモリ？それはあなたがあなたのJSPページをどれだけうまくコーディングしてテストするかに依存します！注意してください！）。ページが小さい場合は、おそらく問題ではありません。
ApacheとTomcatの間にある種のシングルサインオンを実装します。これは、Cookieベースの場合もあれば、（セッションを追跡するバックエンド認証サーバーの場合のように）さらに洗練されたものの場合もあります。このようにして、Apacheは、https：//ページを要求しているユーザーが適切に認証されていることを認識し、そうでない場合は要求を拒否します。長所：完全にスケーラブルです。短所：セットアップが難しく、ソリューションの多くは商用/有料製品です。