Squidのパスワードファイルを変更しても、その後のリクエストが毎回ヘルパーを呼び直すとは限りません。Basic認証では、Squidは検証に成功したユーザー名とパスワードの組をキャッシュできます。

Squid 6.13で、その検証を有効とみなす期間を制御する設定はcredentialsttlです。例:

auth_param basic credentialsttl 5 minutes

これはポリシー値の一例であり、すべての環境への推奨値ではありません。許容できる失効の遅延と、認証バックエンドが処理できる負荷に応じて選びます。

三つの確認を分ける

まず、編集したのが稼働中のヘルパーが使用するファイルか確認します。使われていないファイルを正しく変更しても効果はありません。次に、ヘルパーがファイルを読み、新しいアカウント情報を検証できるか確認します。最後に、稼働中のインスタンスを通じて新たなプロキシリクエストを試します。そこでは認証情報のキャッシュとアクセス規則も適用されます。

ヘルパーと稼働中のプロキシは別々に確認します。ヘルパーは現在のバックエンドでの受け入れを示しますが、Squidはキャッシュ済みの検証結果を引き続き使うことがあります。認証情報の切り替え時には、新しい情報が機能することと、適用される検証期間を過ぎると古い情報が拒否されることの両方を確認します。

この動作の調査には専用のテストアカウントを使います。リクエスト、クライアントの送信元、接続先をそろえ、共有するコマンド出力に本物のパスワードを入れないようにします。

ファイル編集に頼らず失効を計画する

検証結果の有効期間を短くすると、バックエンドの処理量が増えます。負荷の高いサービス全体で短縮する前に、ヘルパーの処理能力を検討し、実際のバックエンドで動作を確認します。利用中のバージョンと構成で確認されていない限り、設定の再読み込みで関連する認証状態がすべて消去されるとは考えないでください。

緊急にアクセスを止めるには、アカウントや送信元を明示的に拒否する規則が別の境界になります。パスワードファイルからの削除だけに頼らず、対象の経路からその拒否を確認してください。

この設定が扱うのはBasicの検証キャッシュです。接続指向の認証方式には追加の状態があり、類推だけで同じ失効モデルを当てはめるべきではありません。

関連記事