Adressen til proxyen forteller Emacs hvor den skal koble til. Påloggingen er en annen del av samtalen. For en vanlig HTTP-forespørsel kan URL-biblioteket til Emacs svare på en autentiseringsutfordring fra proxyen, hente legitimasjon fra auth-source eller spørre interaktivt, og gjenbruke legitimasjon som holdes i økten.

Detaljene nedenfor følger Emacs 31.1. De gjelder operasjoner som bruker URL-biblioteket; en ekstern nedlaster som startes av en Emacs-pakke, har sin egen autentiseringsvei.

Sett ruten, og la deretter HTTP be om påloggingen

Et fast proxy-endepunkt kan velges med det dokumenterte alternativet:

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

Erstatt plassholderen med endepunktet du har fått. Nøklene beskriver URL-skjemaene til målet. Å legge til HTTPS-oppføringen velger en rute for HTTPS-mål; den skaffer ikke legitimasjon i seg selv.

Under en vanlig HTTP-forespørsel kan en proxy svare med 407 Proxy Authentication Required og en Proxy-Authenticate-utfordring. URL-biblioteket velger et støttet autentiseringsskjema og henter legitimasjon for proxy-endepunktet. Deretter prøver det på nytt med Proxy-Authorization.

For Basic-autentisering kan en interaktiv forespørsel spørre om brukernavn og passord når passende legitimasjon ikke er tilgjengelig. En forespørsel merket som ikke-interaktiv kan ikke stole på disse spørsmålene. Proxy-påloggingen er også atskilt fra påloggingen på mål-nettstedet: et nettsteds 401-utfordring følger en annen vei.

Legg vedvarende legitimasjon i auth-source

Hvis auth-source allerede leser en kryptert legitimasjonsfil som ~/.authinfo.gpg, har en Basic-oppføring for dette eksempelet følgende form:

machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD

Bruk din faktiske konto og hemmelighet, og sørg for at filen er blant de konfigurerte auth-sources. Linjen illustrerer felter som samsvarer; den er ikke en instruksjon om å legge et passord i Lisp-initialiseringsfilen din.

To detaljer er viktige i Basic-implementasjonen i Emacs 31.1. Den slår opp vertsnavnet til proxyen uten den numeriske TCP-porten, og den sender URL-skjemaet til proxyen som portverdien til auth-source. For denne HTTP-proxyen er den verdien http, selv om TCP-tilkoblingen bruker port 8080.

Dette oppslaget omfatter ikke utfordringens realm eller den numeriske proxy-porten. Ikke forvent at det velger ulike Basic-passord for flere realms eller proxy-porter på samme vertsnavn. Digest bruker et annet vertsoppslag, så eksempelet ovenfor er spesielt for Basic.

URL-biblioteket holder også sin egen autentiseringshurtigbuffer. Basic-oppføringene skiller mellom proxy-endepunkter og bruker realm- eller katalogtreff innenfor et endepunkt; hurtigbufferen er atskilt fra auth-source-oppslaget. Å skrive et passord ved en forespørsel kan fylle øktbufferen uten å lagre en ny oppføring i den vedvarende legitimasjonsfilen din.

HTTPS har et tidligere autentiseringstrinn

For et HTTPS-mål gjennom en HTTP-proxy sender Emacs først CONNECT. Autentisering kan derfor være nødvendig før den når den krypterte forbindelsen til nettstedet.

I Emacs 31.1 kontrollerer byggeren av CONNECT-forespørselen autentisering som allerede er tilgjengelig gjennom autentiseringsmaskineriet, inkludert hurtiglagret Basic-legitimasjon. Basic-veien spør ikke og henter ikke en fersk auth-source-oppføring på det punktet. En CONNECT-respons som ikke er 200, går heller ikke inn i den vanlige HTTP 407-utfordringshåndtereren beskrevet ovenfor.

Følgelig garanterer ikke en auth-source-oppføring som kan svare på en vanlig HTTP Basic-utfordring, at den første HTTPS-forespørselen i en ny økt autentiseres vellykket. En økt med passende hurtiglagret legitimasjon har en annen starttilstand. Gjentatt redigering av samme passordoppføring kan ikke alene fjerne denne forskjellen mellom de to veiene.

Hvis en HTTPS-operasjon stopper ved proxyen, fastslå om CONNECT fikk 407, og om du bruker oppførselen i denne utgivelsen. Bekreft også autentiseringsskjemaet proxyen tilbyr. En Basic-legitimasjonsoppføring er ikke en universell adapter for alle bedriftsautentiseringssystemer.

Behold den varige konfigurasjonen i det offentlige proxy-alternativet og i legitimasjonsbakenden du har valgt. URL-bibliotekets interne Basic-lager er nyttig for å forstå denne oppførselen, men å fylle den private datastrukturen manuelt ville binde oppsettet til implementasjonsdetaljer.

Relaterte artikler