407 kodeak proxyan autentifikatzea eskatzen du. 401 kodeak helmugako baliabiderako autentifikazioa eskatzen du. Eskaera batek biak aurki ditzake; pasahitza eman aurretik, argitu nork eskatzen duen.

Konparatu egoera eta autentifikazio-erronkaren goiburuak

ErantzunaErronkaren goiburuaKredentzialen goiburuaParte-hartzailea
407 Proxy Authentication RequiredProxy-AuthenticateProxy-AuthorizationBitarteko proxy bat
401 UnauthorizedWWW-AuthenticateAuthorizationJatorrizko baliabidearen autentifikazio-fluxua

Egoera funtsezko lehen arrastoa da, baina aztertu truke osoa. Orriko testuan 407 agertzea ez da benetako HTTP 407 erantzunaren baliokidea. Era berean, saioa hasteko orri pertsonalizatu batek 200 itzul dezake eta aplikazio-geruzan autentifikazioa eskatzen jarraitu.

Zergatik huts egin dezake HTTPSk 407 kodearekin webgunera heldu aurretik?

Ohiko HTTP proxy batek HTTPS eskaera garraiatzen duenean, bezeroak normalean lehenik CONNECT tunela eskatzen du. Proxyak CONNECT eskaera horretarako autentifikazioa eska dezake. Bukatu ez bada, helmugako TLS saioa ez da oraindik tunelaren bidez ezarri. Webgunearen API tokena aldatzeak, beraz, nekez konponduko du etapa hori.

Erabili irteera xehea erronka non agertzen den ikusteko:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Ordezkatu tokiko entzulea zurearekin eta irakurri erregistroko lehen erronka. CONNECT bitarteko 407 helmugako TLSaren aurrekoa da; ondorengo 401 tunela ondo ezarri eta gero ager daiteke.

Eman proxyaren kredentzialak proxy-interfazearen bidez

Konfiantzazko administratzaile batek emandako amaierako puntu eta konturako, curl-ek autentifikazio-eskema negoziatu eta falta den pasahitza eska dezake:

curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/

Ordezkatu adibideko amaierako puntua eta erabiltzailea erabiltzeko baimena duzun zerbitzuaren datuekin. Erabiltzailea bakarrik emateak pasahitza zuzenean goiko komandoan jartzea saihesten du. Onartutako metodoak curl-en konpilazioaren eta proxyaren araberakoak dira; negoziazioak huts egiten badu, aztertu benetako erronka eta konpilazioaren gaitasunak.

Proxy-autentifikazioaren aukera curl-en jatorrizko erabiltzailearen autentifikaziotik bereizita dago. Ez gehitu jatorrirako Authorization goiburua proxyaren erronkari erantzutearen ordez. Ez birbidali proxyaren kredentzial-goiburuak eskuz zerikusirik gabeko eskaerei, eta ez gorde aplikazio osoan berrerabiltzen diren goiburuetan.

Proxyak 407 itzultzen jarraitzen badu

  • Ziurtatu nahi duzun proxyaren ostalaria eta ataka erabiltzen ari zarela.
  • Egiaztatu proxyak iragarritako eskemak, Basic dela pentsatu beharrean.
  • Egiaztatu kontuaren egoera eta zerbitzuak erabiltzaile-izenaren formatu jakina eskatzen duen.
  • Aztertu karaktere berezien bidalketa kredentzialak URL batean badaude.
  • Argitu nabigatzailean integratutako enpresa-autentifikazioak exekuzio-ingurunearen edo plataformaren laguntza behar duen.
  • Bezeroaren frogak nahikoak ez badira, eskatu administratzaileari datu sentikorrik gabeko eskaera-identifikatzailea edo zerbitzariko erregistro-sarrera.

403 edo baztertutako CONNECT sarbide-politikaren erabakia izan daiteke, saioa ondo hasi ondoren ere. Pasahitz gehiago saiatzeak ez du debekatutako helmugarako sarbiderik emango.

Helmugako HTTPSk ez du proxy-kredentzialen truke oro babesten

Proxyaren autentifikazioa helmugako TLSa ezarri aurretik gerta daiteke. Proxyarekiko konexioa zifratu gabe badago eta metodoak kredentzial berrerabilgarriak agerian uzten baditu bertan, HTTPS helmugak ez du aurreko trukea atzeraeraginez babesten. Aukeratu zerbitzuari egokitutako garraioa eta autentifikazioa, eta ez bidali kontu pribatuak proxy publiko ezezagunari.

Aztertu erregistro xeheak partekatu aurretik. Tresnak ohiko kredentzial-eremuak estaltzen baditu ere, erabiltzaile-izenak, barneko amaierako puntuen izenak, cookieak edo identifikatzeko bestelako datuak gera daitezke.

Erlazionatutako artikuluak