Вход през прокси URL в Emacs 31.1: auth-source и ограничения на CONNECT

Адресът на проксито казва на Emacs къде да се свърже. Входът е друга част от разговора. При обикновена HTTP заявка URL библиотеката на Emacs може да отговори на предизвикателство за удостоверяване на проксито, да получи идентификационни данни от 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.

Две подробности са важни в Basic реализацията на Emacs 31.1. Тя търси името на хоста на проксито без цифровия TCP порт и подава схемата на URL адреса на проксито като стойност на порта за auth-source. За това HTTP прокси тази стойност е http, въпреки че TCP връзката използва порт 8080.

Това търсене не включва realm на предизвикателството или цифровия порт на проксито. Не очаквайте то да избере различни Basic пароли за няколко realm-а или порта на проксито при едно и също име на хост. Digest използва различно търсене на хост, така че примерът по-горе е специално за Basic.

URL библиотеката също поддържа свой собствен кеш за удостоверяване. Неговите Basic записи различават крайните точки на проксито и използват съвпадение по realm или директория в рамките на крайна точка; този кеш е отделен от търсенето в auth-source. Въвеждането на парола при подкана може да запълни кеша на сесията, без да запазва нов запис във файла ви с постоянни идентификационни данни.

HTTPS има по-ранна стъпка за удостоверяване

За HTTPS местоназначение през HTTP прокси Emacs първо изпраща CONNECT. Затова удостоверяване може да е необходимо, преди да достигне криптираната връзка със сайта.

В Emacs 31.1 конструкторът на CONNECT заявката проверява за вече налично удостоверяване чрез своя механизъм за удостоверяване, включително кеширани Basic идентификационни данни. Неговият Basic път не подканва и не извлича нов запис от auth-source в този момент. Отговор на CONNECT, различен от 200, също не влиза в обикновения манипулатор на HTTP 407 предизвикателство, описан по-горе.

Следователно запис в auth-source, който може да отговори на нормално HTTP Basic предизвикателство, не гарантира, че първата HTTPS заявка на нова сесия ще се удостовери успешно. Сесия с подходящи кеширани идентификационни данни има различно начално състояние. Многократното редактиране на един и същ запис с парола не може само по себе си да премахне тази разлика между двата пътя.

Ако HTTPS операция спре при проксито, установете дали CONNECT е получил 407 и дали използвате поведението на тази версия. Потвърдете и схемата за удостоверяване, която проксито предлага. Basic записът с идентификационни данни не е универсален адаптер за всяка корпоративна система за удостоверяване.

Пазете дълготрайната конфигурация в публичната опция за прокси и в избраната от вас система за идентификационни данни. Вътрешното Basic хранилище на URL библиотеката е полезно за разбиране на това поведение, но ръчното запълване на тази частна структура от данни би обвързало настройката с детайли на реализацията.