URL-proxy-innlogging i Emacs 31.1: auth-source og CONNECT-grenser

Adressa til proxyen fortel Emacs kvar det skal kopla til. Innlogginga er ein annan del av samtalen. For ei vanleg HTTP-førespurnad kan URL-biblioteket til Emacs svara på ei autentiseringsutfordring frå proxyen, hente legitimasjon frå auth-source eller spørje interaktivt, og bruke legitimasjon som blir halden i økta, om att.

Detaljane nedanfor følgjer Emacs 31.1. Dei gjeld operasjonar som brukar URL-biblioteket; ein ekstern nedlastar som ein Emacs-pakke startar, har sin eigen autentiseringsveg.

Set ruta, og lat så HTTP be om innlogginga

Eit fast proxy-endepunkt kan veljast med det dokumenterte alternativet:

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

Bytt ut plasshaldaren med endepunktet du fekk. Nøklane skildrar URL-skjemaa til målet. Å leggje til HTTPS-oppføringa vel ei rute for HTTPS-mål; ho skaffar ikkje legitimasjon i seg sjølv.

Under ei vanleg HTTP-førespurnad kan ein proxy svara med 407 Proxy Authentication Required og ei Proxy-Authenticate-utfordring. URL-biblioteket vel eit støtta autentiseringsskjema og hentar legitimasjon for proxy-endepunktet. Deretter prøver det på nytt med Proxy-Authorization.

For Basic-autentisering kan ei interaktiv førespurnad spørje om brukarnamn og passord når høveleg legitimasjon ikkje er tilgjengeleg. Ei førespurnad merkt som ikkje-interaktiv kan ikkje stole på dei spørsmåla. Proxy-innlogginga er også skild frå innlogginga på mål-nettstaden: 401-utfordringa til ein nettstad følgjer ein annan veg.

Legg varig legitimasjon i auth-source

Viss auth-source allereie les ei kryptert legitimasjonsfil som ~/.authinfo.gpg, har ei Basic-oppføring for dette dømet denne forma:

machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD

Bruk din faktiske konto og løyndom, og pass på at fila er blant dei oppsette auth-sources. Linja illustrerer felt som samsvarar; ho er ikkje ei oppskrift på å leggje eit passord i Lisp-initialiseringsfila di.

To detaljar er viktige i Basic-implementasjonen i Emacs 31.1. Han slår opp vertsnamnet til proxyen utan den numeriske TCP-porten, og han sender URL-skjemaet til proxyen som portverdi for auth-source. For denne HTTP-proxyen er den verdien http, sjølv om TCP-tilkoplinga brukar port 8080.

Dette oppslaget omfattar ikkje realm til utfordringa eller den numeriske proxy-porten. Ikkje vent at det vel ulike Basic-passord for fleire realms eller proxy-portar på same vertsnamn. Digest brukar eit anna vertsoppslag, så dømet ovanfor er særskilt for Basic.

URL-biblioteket held også sin eigen autentiseringsbuffer. Basic-oppføringane skil mellom proxy-endepunkt og brukar realm- eller katalogtreff innanfor eit endepunkt; bufferen er skild frå auth-source-oppslaget. Å skrive eit passord ved ei oppmoding kan fylle øktbufferen utan å lagre ei ny oppføring i den varige legitimasjonsfila di.

HTTPS har eit tidlegare autentiseringstrinn

For eit HTTPS-mål gjennom ein HTTP-proxy sender Emacs først CONNECT. Autentisering kan difor vere nødvendig før det når den krypterte tilkoplinga til nettstaden.

I Emacs 31.1 kontrollerer byggjaren av CONNECT-førespurnaden autentisering som allereie er tilgjengeleg gjennom autentiseringsmaskineriet, inkludert hurtiglagra Basic-legitimasjon. Basic-vegen spør ikkje og hentar ikkje ei fersk auth-source-oppføring på det punktet. Eit CONNECT-svar som ikkje er 200, går heller ikkje inn i den vanlege HTTP 407-utfordringshandsamararen som er skild ovanfor.

Følgjeleg garanterer ikkje ei auth-source-oppføring som kan svara på ei vanleg HTTP Basic-utfordring, at den første HTTPS-førespurnaden i ei ny økt blir autentisert med suksess. Ei økt med høveleg hurtiglagra legitimasjon har ein annan starttilstand. Gjenteken redigering av same passordoppføringa kan ikkje åleine fjerne denne skilnaden mellom dei to vegane.

Viss ein HTTPS-operasjon stoppar ved proxyen, fastslå om CONNECT fekk 407, og om du brukar åtferda i denne utgåva. Stadfest også autentiseringsskjemaet som proxyen tilbyr. Ei Basic-legitimasjonsoppføring er ikkje ein universell adapter for alle verksemdsautentiseringssystem.

Hald den varige konfigurasjonen i det offentlege proxy-alternativet og i legitimasjonsbakenden du valde. Den interne Basic-lagra til URL-biblioteket er nyttig for å forstå denne åtferda, men å fylle den private datastrukturen manuelt ville binde oppsettet til implementasjonsdetaljar.