Emacs 31.1 の URL プロキシログイン: auth-source と CONNECT の制限

プロキシのアドレスは、Emacs にどこへ接続するかを伝えます。そのログインは会話の別の部分です。通常の HTTP リクエストでは、Emacs の URL ライブラリはプロキシの認証チャレンジに応答し、auth-source から認証情報を取得するか対話的に尋ね、セッション内に保持された認証情報を再利用できます。

以下の詳細は Emacs 31.1 に従います。URL ライブラリを使う操作に関係します。Emacs パッケージが起動する外部ダウンローダには、独自の認証経路があります。

経路を設定し、HTTP にログインを尋ねさせる

固定のプロキシエンドポイントは、文書化されたオプションで選択できます。

(setq url-proxy-services
      '(("http" . "proxy.example:8080")
        ("https" . "proxy.example:8080")))

プレースホルダーを提供されたエンドポイントに置き換えます。キーは宛先 URL のスキームを表します。HTTPS の項目を加えると HTTPS 宛先の経路が選ばれますが、それ自体が認証情報を供給するわけではありません。

通常の HTTP リクエストの途中で、プロキシは 407 Proxy Authentication Required と Proxy-Authenticate チャレンジで応答することがあります。URL ライブラリは対応する認証スキームを選び、プロキシエンドポイントの認証情報を取得します。その後 Proxy-Authorization で再試行します。

Basic 認証では、適切な認証情報がない場合に対話的なリクエストがユーザー名とパスワードを尋ねることがあります。非対話的とされたリクエストは、その問い合わせに頼れません。プロキシのログインは宛先ウェブサイトのログインとも別です。ウェブサイトの 401 チャレンジは別の経路をたどります。

永続的な認証情報を auth-source に置く

auth-source がすでに ~/.authinfo.gpg のような暗号化された認証情報ファイルを読んでいる場合、この例の Basic エントリは次の形になります。

machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD

実際のアカウントと秘密を使用し、ファイルが設定済みの auth-sources に含まれていることを確認してください。この行は一致するフィールドを示すものであり、Lisp の初期化ファイルにパスワードを書く指示ではありません。

Emacs 31.1 の Basic 実装では 2 つの点が重要です。数値の TCP ポートを付けずにプロキシのホスト名を検索し、プロキシ URL のスキームを auth-source のポート値として渡します。この HTTP プロキシでは、TCP 接続がポート 8080 を使っていても、その値は http です。

この検索にはチャレンジの realm も数値のプロキシポートも含まれません。同じホスト名上の複数の realm やプロキシポートに対して異なる Basic パスワードを選ぶことは期待しないでください。Digest は別のホスト検索を使うため、上の例は Basic 専用です。

URL ライブラリは独自の認証キャッシュも保持します。Basic エントリはプロキシエンドポイントを区別し、エンドポイント内で realm またはディレクトリの照合を使います。そのキャッシュは auth-source の検索とは別です。プロンプトでパスワードを入力すると、永続的な認証情報ファイルに新しいエントリを保存することなくセッションキャッシュを満たせます。

HTTPS にはより早い認証段階がある

HTTP プロキシ経由の HTTPS 宛先では、Emacs はまず CONNECT を送ります。そのため、ウェブサイトへの暗号化接続に到達する前に認証が必要になることがあります。

Emacs 31.1 では、CONNECT リクエストの構築時に、認証機構を通じてすでに利用可能な認証を確認します。キャッシュされた Basic 認証情報も含まれます。その Basic 経路はその時点で新しい auth-source エントリを尋ねたり取得したりしません。200 以外の CONNECT 応答も、上で説明した通常の HTTP 407 チャレンジ処理には入りません。

したがって、通常の HTTP Basic チャレンジに応答できる auth-source エントリがあっても、新しいセッションの最初の HTTPS リクエストが正常に認証される保証はありません。適切なキャッシュ済み認証情報を持つセッションは開始状態が異なります。同じパスワードエントリを繰り返し編集しても、それだけでは 2 つの経路の差は解消しません。

HTTPS 操作がプロキシで止まる場合は、CONNECT が 407 を受け取ったか、このリリースの動作を使っているかを確認してください。プロキシが提示する認証スキームも確認してください。Basic 認証情報のエントリは、あらゆる企業認証システムに対する万能のアダプターではありません。

永続的な設定は公開のプロキシオプションと、選んだ認証情報バックエンドに置いてください。URL ライブラリの内部 Basic ストアはこの動作を理解するのに役立ちますが、その非公開のデータ構造を手で埋めると、設定が実装の詳細に結び付きます。