Adres serwera proxy mówi Emacsowi, gdzie się połączyć. Logowanie to kolejna część rozmowy. W przypadku zwykłego żądania HTTP biblioteka URL Emacsa może odpowiedzieć na wyzwanie uwierzytelniania serwera proxy, pobrać dane logowania z auth-source lub zapytać interaktywnie, a także użyć ponownie danych logowania przechowywanych w sesji.

Poniższe szczegóły dotyczą Emacsa 31.1. Odnoszą się do operacji używających biblioteki URL; zewnętrzny program pobierający uruchamiany przez pakiet Emacsa ma własną ścieżkę uwierzytelniania.

Ustaw trasę, a następnie pozwól HTTP poprosić o logowanie

Stały punkt końcowy serwera proxy można wybrać za pomocą udokumentowanej opcji:

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

Zastąp symbol zastępczy podanym punktem końcowym. Klucze opisują schematy URL celu. Dodanie wpisu HTTPS wybiera trasę dla celów HTTPS; samo w sobie nie dostarcza danych logowania.

Podczas zwykłego żądania HTTP serwer proxy może odpowiedzieć 407 Proxy Authentication Required i wyzwaniem Proxy-Authenticate. Biblioteka URL wybiera obsługiwany schemat uwierzytelniania i pobiera dane logowania dla punktu końcowego serwera proxy. Następnie ponawia próbę z Proxy-Authorization.

W przypadku uwierzytelniania Basic żądanie interaktywne może poprosić o nazwę użytkownika i hasło, gdy odpowiednie dane nie są dostępne. Żądanie oznaczone jako nieinteraktywne nie może polegać na tych pytaniach. Logowanie do serwera proxy jest też oddzielone od logowania do docelowej witryny: wyzwanie 401 witryny podąża inną ścieżką.

Umieść trwałe dane logowania w auth-source

Jeśli auth-source już odczytuje zaszyfrowany plik danych logowania, taki jak ~/.authinfo.gpg, wpis Basic dla tego przykładu ma następującą postać:

machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD

Użyj swojego rzeczywistego konta i sekretu oraz upewnij się, że plik należy do skonfigurowanych auth-sources. Wiersz ilustruje pasujące pola; nie jest instrukcją umieszczenia hasła w pliku inicjalizacyjnym Lisp.

W implementacji Basic w Emacsie 31.1 istotne są dwa szczegóły. Wyszukuje nazwę hosta serwera proxy bez numerycznego portu TCP i przekazuje schemat URL serwera proxy jako wartość portu dla auth-source. Dla tego serwera proxy HTTP tą wartością jest http, mimo że połączenie TCP używa portu 8080.

To wyszukiwanie nie obejmuje realm wyzwania ani numerycznego portu serwera proxy. Nie oczekuj, że wybierze różne hasła Basic dla kilku realms lub portów serwera proxy na tej samej nazwie hosta. Digest używa innego wyszukiwania hosta, więc powyższy przykład dotyczy konkretnie Basic.

Biblioteka URL prowadzi też własną pamięć podręczną uwierzytelniania. Jej wpisy Basic rozróżniają punkty końcowe serwera proxy i używają dopasowania realm lub katalogu w obrębie punktu końcowego; ta pamięć jest oddzielona od wyszukiwania w auth-source. Wpisanie hasła w monicie może wypełnić pamięć sesji bez zapisywania nowego wpisu w trwałym pliku danych logowania.

HTTPS ma wcześniejszy etap uwierzytelniania

Dla celu HTTPS przez serwer proxy HTTP Emacs najpierw wysyła CONNECT. Uwierzytelnianie może więc być potrzebne, zanim dotrze do szyfrowanego połączenia z witryną.

W Emacsie 31.1 konstruktor żądania CONNECT sprawdza uwierzytelnianie już dostępne przez jego mechanizm uwierzytelniania, w tym dane Basic w pamięci podręcznej. Jego ścieżka Basic nie pyta ani nie pobiera świeżego wpisu auth-source w tym momencie. Odpowiedź CONNECT inna niż 200 również nie trafia do zwykłego programu obsługi wyzwania HTTP 407 opisanego powyżej.

W konsekwencji wpis auth-source, który potrafi odpowiedzieć na normalne wyzwanie HTTP Basic, nie gwarantuje, że pierwsze żądanie HTTPS nowej sesji zostanie pomyślnie uwierzytelnione. Sesja z odpowiednimi danymi w pamięci podręcznej ma inny stan początkowy. Wielokrotne edytowanie tego samego wpisu hasła samo w sobie nie usuwa tej różnicy między obiema ścieżkami.

Jeśli operacja HTTPS zatrzyma się na serwerze proxy, ustal, czy CONNECT otrzymał 407 i czy używasz zachowania tego wydania. Potwierdź też schemat uwierzytelniania oferowany przez serwer proxy. Wpis danych Basic nie jest uniwersalnym adapterem dla każdego korporacyjnego systemu uwierzytelniania.

Trzymaj trwałą konfigurację w publicznej opcji serwera proxy i w wybranym backendzie danych logowania. Wewnętrzny magazyn Basic biblioteki URL jest przydatny do zrozumienia tego zachowania, ale ręczne wypełnianie tej prywatnej struktury danych wiązałoby konfigurację ze szczegółami implementacji.

Powiązane artykuły