私はこの正確な問題を解決しなければなりませんでした。私が思いついた唯一の解決策は、リバース プロキシを使用することです。これは次のように機能します。
Browser (request without basic authentication) -> Reverse Proxy (request with added basic authentication) -> Destination server (requires basic authentication)
そのため、宛先サーバーとは別の場所でリバース プロキシが実行されています。基本認証の詳細はリバース プロキシに格納されます。
の URL がiframe次のようになっているとします (リバース プロキシがポートで実行されていると仮定します8088)。
<iframe src="http://proxy_id.proxy_host.com:8088/cgi-bin/some/path"></iframe>
リバース プロキシは、リクエストを次のように変換します。
http://destination_host.com:PORT/cgi-bin/some/path
ここdestination_hostでPORT、基本認証の詳細 (要求ヘッダーとして宛先サーバーに送信されるため、URL に表示されなくなります) は、元の URL にあった に基づいて、リバース プロキシ構成から取得されproxy_idます。
リバース プロキシはhostヘッダーを ( から*.proxy_host.comにdestination_host.com) 変更しますが、パスは変更しません。したがって、プロキシは、CSS または JavaScript ファイルをダウンロードするためのサブリクエストを含む、ブラウザからのすべてのリクエスト、または開始されたリクエストに対して透過的です。 JavaScript から。
このセットアップにproxy_id.proxy_host.comは、リバース プロキシdestination_host.comの IP に解決され、宛先サーバーの IP に解決されるように、適切な DNS エントリが必要です。要件によってはproxy_host、実際にはdestination_host(プロキシが宛先サーバーで実行されている場合など) と同じになる場合があります。
それが基本的な考え方でした。私のプロジェクトでは、プロキシ構成を動的に追加できるため、メイン ドメインのすべてのサブドメインが*.some_host.com同じリバース プロキシ IP に解決されるようにする必要がありました。デフォルトのWindowsファイルは(キャッチオール)としてサブドメインをサポートしていないため、アクリルDNSを使用しています。hosts*
プロジェクトの要件によっては、その目的に使用できる適切なリバース プロキシを見つけることができる場合があります。私のプロジェクトは Erlang で書かれており、使用できるプロキシが見つからなかったため、独自のプロキシを実装しました。github: yoonka/charreadaで確認してください。まだドキュメントはありませんが、コードはかなり単純です。これは、任意の言語で書かれた任意のプロジェクトで使用できる可能性がありますが、現在の制限は、Erlang 呼び出しを使用して構成が追加されていることです (私のプロジェクトでは、別の Erlang アプリケーションから提供されているように)。静的ファイルからの構成の読み取りと、より良いドキュメントは、それに対する需要がある場合にのみ追加できます:)