Connexion au proxy URL dans Emacs 31.1 : auth-source et limites de CONNECT
Configurez un proxy HTTP authentifié pour la bibliothèque URL d'Emacs, comprenez sa recherche d'identifiants Basic et tenez compte du chemin HTTPS CONNECT dans Emacs 31.1.
L'adresse du proxy indique à Emacs où se connecter. Son identifiant est une autre partie de la conversation. Pour une requête HTTP ordinaire, la bibliothèque URL d'Emacs peut répondre à une demande d'authentification du proxy, obtenir des identifiants depuis auth-source ou les demander de façon interactive, et réutiliser les identifiants conservés dans la session.
Les détails ci-dessous suivent Emacs 31.1. Ils concernent les opérations qui utilisent la bibliothèque URL ; un téléchargeur externe lancé par un paquet Emacs a son propre chemin d'authentification.
Définissez la route, puis laissez HTTP demander l'identifiant
Un point de terminaison de proxy fixe peut être choisi avec l'option documentée :
(setq url-proxy-services
'(("http" . "proxy.example:8080")
("https" . "proxy.example:8080")))
Remplacez l'espace réservé par le point de terminaison fourni. Les clés décrivent les schémas d'URL de destination. Ajouter l'entrée HTTPS sélectionne une route pour les destinations HTTPS ; elle ne fournit pas elle-même d'identifiants.
Lors d'une requête HTTP ordinaire, un proxy peut répondre avec 407 Proxy Authentication Required et un défi Proxy-Authenticate. La bibliothèque URL choisit un schéma d'authentification pris en charge et obtient des identifiants pour le point de terminaison du proxy. Elle réessaie ensuite avec Proxy-Authorization.
Pour l'authentification Basic, une requête interactive peut demander un nom d'utilisateur et un mot de passe lorsque des identifiants appropriés ne sont pas disponibles. Une requête marquée comme non interactive ne peut pas compter sur ces invites. La connexion au proxy est aussi distincte de la connexion au site web de destination : le défi 401 d'un site web suit un autre chemin.
Placez les identifiants persistants dans auth-source
Si auth-source lit déjà un fichier d'identifiants chiffré comme ~/.authinfo.gpg, une entrée Basic pour cet exemple a la forme suivante :
machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD
Utilisez votre véritable compte et votre secret, et assurez-vous que le fichier figure parmi vos auth-sources configurés. La ligne illustre les champs correspondants ; ce n'est pas une instruction pour mettre un mot de passe dans votre fichier d'initialisation Lisp.
Deux détails comptent dans l'implémentation Basic d'Emacs 31.1. Elle recherche le nom d'hôte du proxy sans le port TCP numérique, et elle transmet le schéma de l'URL du proxy comme valeur de port pour auth-source. Pour ce proxy HTTP, cette valeur est http, même si la connexion TCP utilise le port 8080.
Cette recherche n'inclut ni le realm du défi ni le port numérique du proxy. Ne vous attendez pas à ce qu'elle sélectionne des mots de passe Basic différents pour plusieurs realms ou ports de proxy sur un même nom d'hôte. Digest utilise une autre recherche d'hôte, aussi l'exemple ci-dessus vise-t-il spécifiquement Basic.
La bibliothèque URL tient aussi son propre cache d'authentification. Ses entrées Basic distinguent les points de terminaison de proxy et utilisent une correspondance de realm ou de répertoire au sein d'un point de terminaison ; ce cache est distinct de la recherche auth-source. Saisir un mot de passe à une invite peut remplir le cache de session sans enregistrer de nouvelle entrée dans votre fichier d'identifiants persistant.
HTTPS a une étape d'authentification plus précoce
Pour une destination HTTPS via un proxy HTTP, Emacs envoie d'abord CONNECT. L'authentification peut donc être nécessaire avant d'atteindre la connexion chiffrée au site web.
Dans Emacs 31.1, le constructeur de requête CONNECT vérifie l'authentification déjà disponible via sa machinerie d'authentification, y compris les identifiants Basic mis en cache. Son chemin Basic n'invite pas et ne récupère pas de nouvelle entrée auth-source à ce moment. Une réponse CONNECT autre que 200 n'entre pas non plus dans le gestionnaire de défi HTTP 407 ordinaire décrit plus haut.
Par conséquent, une entrée auth-source capable de répondre à un défi HTTP Basic normal ne garantit pas que la première requête HTTPS d'une nouvelle session s'authentifiera correctement. Une session disposant d'identifiants mis en cache appropriés a un état initial différent. Modifier sans cesse la même entrée de mot de passe ne peut pas à lui seul supprimer cette différence entre les deux chemins.
Si une opération HTTPS s'arrête au niveau du proxy, déterminez si CONNECT a reçu 407 et si vous utilisez le comportement de cette version. Confirmez aussi le schéma d'authentification proposé par le proxy. Une entrée d'identifiants Basic n'est pas un adaptateur universel pour tout système d'authentification d'entreprise.
Conservez la configuration durable dans l'option publique du proxy et dans le backend d'identifiants que vous avez choisi. Le stockage Basic interne de la bibliothèque URL est utile pour comprendre ce comportement, mais remplir à la main cette structure de données privée lierait l'installation à des détails d'implémentation.