URL-proxy-login i Emacs 31.1: auth-source og CONNECT-grænser

Proxyens adresse fortæller Emacs, hvor der skal forbindes. Dens login er en anden del af samtalen. Ved en almindelig HTTP-anmodning kan Emacs' URL-bibliotek besvare en godkendelsesudfordring fra proxyen, hente legitimationsoplysninger fra auth-source eller spørge interaktivt og genbruge oplysninger, der holdes i sessionen.

Detajlerne nedenfor følger Emacs 31.1. De vedrører handlinger, der bruger URL-biblioteket; en ekstern downloader, der startes af en Emacs-pakke, har sin egen godkendelsesvej.

Sæt ruten, og lad så HTTP bede om login

Et fast proxy-endepunkt kan vælges med den dokumenterede indstilling:

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

Erstat pladsholderen med det angivne endepunkt. Nøglerne beskriver destinations-URL-skemaer. Tilføjelsen af HTTPS-posten vælger en rute til HTTPS-destinationer; den leverer ikke selv legitimationsoplysninger.

Under en almindelig HTTP-anmodning kan en proxy svare med 407 Proxy Authentication Required og en Proxy-Authenticate-udfordring. URL-biblioteket vælger et understøttet godkendelsesskema og henter legitimationsoplysninger til proxy-endepunktet. Derefter prøver det igen med Proxy-Authorization.

Ved Basic-godkendelse kan en interaktiv anmodning spørge om brugernavn og adgangskode, når passende legitimationsoplysninger ikke er tilgængelige. En anmodning markeret som ikke-interaktiv kan ikke stole på disse forespørgsler. Proxy-loginet er også adskilt fra destinationswebstedets login: et websteds 401-udfordring følger en anden vej.

Læg vedvarende legitimationsoplysninger i auth-source

Hvis auth-source allerede læser en krypteret legitimationsfil som ~/.authinfo.gpg, har en Basic-post til dette eksempel følgende form:

machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD

Brug din faktiske konto og hemmelighed, og sørg for, at filen er blandt dine konfigurerede auth-sources. Linjen illustrerer matchende felter; det er ikke en instruktion om at lægge en adgangskode i din Lisp-initialiseringsfil.

To detaljer er vigtige i Emacs 31.1's Basic-implementering. Den slår proxyens værtsnavn op uden den numeriske TCP-port, og den sender proxy-URL'ens skema som auth-source' portværdi. For denne HTTP-proxy er den værdi http, selvom TCP-forbindelsen bruger port 8080.

Dette opslag omfatter ikke udfordringens realm eller den numeriske proxy-port. Forvent ikke, at det vælger forskellige Basic-adgangskoder til flere realms eller proxy-porte på samme værtsnavn. Digest bruger et andet værtsopslag, så eksemplet ovenfor er specifikt for Basic.

URL-biblioteket holder også sin egen godkendelsescache. Dets Basic-poster skelner mellem proxy-endepunkter og bruger realm- eller mappematchning inden for et endepunkt; denne cache er adskilt fra auth-source-opslaget. Indtastning af en adgangskode ved en forespørgsel kan fylde sessionens cache uden at gemme en ny post i din vedvarende legitimationsfil.

HTTPS har et tidligere godkendelsestrin

For en HTTPS-destination gennem en HTTP-proxy sender Emacs først CONNECT. Godkendelse kan derfor være nødvendig, før den når den krypterede forbindelse til webstedet.

I Emacs 31.1 kontrollerer CONNECT-anmodningsbyggeren for godkendelse, der allerede er tilgængelig gennem dens godkendelsesmaskineri, herunder cachelagrede Basic-oplysninger. Dets Basic-vej spørger ikke og henter ikke en frisk auth-source-post på det tidspunkt. Et CONNECT-svar, der ikke er 200, går heller ikke ind i den almindelige HTTP 407-udfordringshåndteringsfunktion, der er beskrevet ovenfor.

Derfor garanterer en auth-source-post, der kan besvare en normal HTTP Basic-udfordring, ikke, at en ny sessions første HTTPS-anmodning godkendes korrekt. En session med passende cachelagrede oplysninger har en anden starttilstand. Gentagen redigering af den samme adgangskodepost kan ikke i sig selv fjerne denne forskel mellem de to veje.

Hvis en HTTPS-handling stopper ved proxyen, skal du fastslå, om CONNECT modtog 407, og om du bruger denne udgivelses adfærd. Bekræft også det godkendelsesskema, proxyen tilbyder. En Basic-legitimationspost er ikke en universel adapter til ethvert virksomhedsgodkendelsessystem.

Behold den varige konfiguration i den offentlige proxy-indstilling og i dit valgte legitimations-baggrunssystem. URL-bibliotekets interne Basic-lager er nyttigt til at forstå denne adfærd, men manuel udfyldning af den private datastruktur ville binde opsætningen til implementeringsdetaljer.