プロキシ認証なしで 1 つの Squid 宛先を許可する
Squid の意図的な認証例外の周囲で、送信元と宛先の制限を維持します。
監視ページはプロキシのログインなしで動作する必要があります。明白なルールは http_access allow status_site です。認証の前に置くと、本来サービスするつもりのなかったクライアントにも例外を与えてしまいます。
Squid 6 または 7 では、例外の条件をまとめておきます。既存の管理、安全でないポート、CONNECT、ローカルサービスの保護の後に、該当部分は次のようになります。
acl office_clients src 192.0.2.0/24
acl status_site dstdomain status.example.net
acl signed_in proxy_auth REQUIRED
http_access allow office_clients status_site
http_access allow office_clients signed_in
http_access deny all
ネットワークとホスト名はプレースホルダーです。認証には引き続き既存のヘルパー設定が必要です。これはアクセス ポリシーの例外部分であり、完全なプロキシ設定ではありません。
1 行目は、ログイン ACL を評価せずに、選択したクライアントにその宛先を許可します。次の行は、それらのクライアントに他の場所を認証後にのみ許可します。以前の広い許可や後の代替経路が結果を変える可能性があるため、インクルードされたファイルを含む順序付きポリシー全体を読んでください。
プロンプトを避けるためだけに、例外を宛先ポートの保護より上へ移動しないでください。意図しないポート上の許可されたサイトは、依然として別の経路です。また、不必要に広いサフィックスを追加するのではなく、正確なホストまたはそのサブドメインを対象にすべきかを決めてください。
ホスト名の例外は一致する宛先を対象とし、そのページが読み込むすべての依存関係を対象とするわけではありません。リダイレクトやサードパーティのアセットは、通常のログイン要件に正当に遭遇する可能性があります。
単純な HTTP では、プロキシは適切な場合により細かい URL 情報を使用できます。通常の HTTPS CONNECT 要求はページのパスを公開しないため、ホスト全体のトンネル例外から「1 ページのみ」というルールを推測することはできません。