HTTP 407 aŭ 401: kiu ensaluto malsukcesas?
Distingu prokurilan kaj retejan aŭtentikigon, inspektu la ĝustajn kapojn kaj ne sendu ensalutajn datumojn al la malĝusta partio.
407 petas aŭtentikigon ĉe la prokurilo. 401 petas ĝin por la celrimedo. Unu peto povas renkonti ambaŭ; eksciu, kiu petas, antaŭ ol doni pasvorton.
Komparu la staton kaj la kapojn de aŭtentikiga defio
| Respondo | Defia kapo | Ensalutdatuma kapo | Koncerna partio |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Meza prokurilo |
| 401 Unauthorized | WWW-Authenticate | Authorization | La aŭtentikiga fluo de la origina rimedo |
La stato estas esenca unua indiko, sed inspektu la tutan interŝanĝon. Paĝo montranta 407 en sia teksto ne egalas al efektiva HTTP 407-respondo. Same, propra ensalutpaĝo povas redoni 200 kaj tamen postuli aŭtentikigon ĉe la aplikaĵa tavolo.
Kial HTTPS povas malsukcesi per 407 antaŭ ol atingi la retejon
Kiam ordinara HTTP-prokurilo portas HTTPS-peton, la kliento kutime unue petas CONNECT-tunelon. La prokurilo povas postuli aŭtentikigon por tiu CONNECT-peto. Se ĝi ne finiĝas, la TLS-sesio kun la celo ankoraŭ ne estas establita tra la tunelo. Ŝanĝi la API-ĵetonon de la retejo do verŝajne ne riparos tiun etapon.
Uzu peton kun detala eligo por vidi, kie aperas la defio:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Anstataŭigu la lokan aŭskultanton per via kaj legu la unuan defion en la protokolo. 407 dum CONNECT aperas antaŭ cela TLS; posta 401 povas sekvi sukcese establitan tunelon.
Donu prokurilajn datumojn per la prokurila interfaco
Por finpunkto kaj konto de fidata administranto, curl povas interkonsenti la prokurilan aŭtentikigan skemon kaj peti mankantan pasvorton:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Anstataŭigu la ekzemplajn finpunkton kaj uzanton per la datumoj de via rajtigita servo. Nur uzantnomo evitas meti la pasvorton rekte en la supran komandon. Subtenataj metodoj varias laŭ la kompilaĵo de curl kaj la prokurilo; ĉe malsukcesa intertraktado kontrolu la efektivan defion kaj la kapablojn de la kompilaĵo.
La prokurila aŭtentikiga opcio estas aparta de la opcio de curl por la origina uzanto. Ne aldonu originan Authorization-kapon anstataŭ respondi al prokurila defio. Ankaŭ ne mane plusendu kapojn kun prokurilaj datumoj al senrilataj petoj aŭ konservu ilin en kapoj reuzataj de la tuta aplikaĵo.
Se la prokurilo daŭre redonas 407
- Konfirmu, ke vi uzas la celitan prokurilan gastiganton kaj pordon.
- Kontrolu la anoncitajn skemojn anstataŭ supozi Basic.
- Konfirmu la kontostaton kaj la uzantnoman formaton postulatan de la servo.
- Kontrolu la transdonon de specialaj signoj, se la datumoj estas en URL.
- Eksciu, ĉu entreprena aŭtentikigo integrita en la retumilo bezonas subtenon de la rultempa medio aŭ platformo.
- Petu de la administranto petidentigilon aŭ servilan protokoleron purigitan de sentemaj datumoj, kiam la klientaj pruvoj ne sufiĉas.
403 aŭ rifuzita CONNECT povas esti decido de la alirpolitiko eĉ post sukcesa ensaluto. Pliaj pasvortprovoj ne donos aliron al malpermesita celo.
La HTTPS de la celo ne protektas ĉiun prokurilan datuminterŝanĝon
Prokurila aŭtentikigo povas okazi antaŭ establo de cela TLS. Se la konekto al la prokurilo mem estas neĉifrita kaj la metodo elmontras reuzeblajn datumojn sur ĝi, HTTPS-celo ne protektas tiun pasintan interŝanĝon retroaktive. Elektu taŭgajn transporton kaj aŭtentikigon por la servo; ne sendu privatajn kontojn al nekonata publika prokurilo.
Reviziu detalajn protokolojn antaŭ ol kundividi ilin. Eĉ se ilo kaŝas oftajn ensalutkampojn, povas resti uzantnomoj, internaj finpunktnomoj, kuketoj aŭ aliaj identigaj datumoj.