HTTP 407 apo 401: cili identifikim po dështon?
Ndani autentikimin e proxy-t nga ai i sajtit, kontrolloni titujt e duhur dhe mos dërgoni kredenciale te pala e gabuar.
407 kërkon autentikim te proxy. 401 kërkon autentikim për burimin e synuar. Një kërkesë mund t’i hasë të dyja, ndaj përcaktoni kush po kërkon përpara se të jepni fjalëkalimin.
Krahasoni statusin dhe titujt e sfidës së autentikimit
| Përgjigjja | Titulli i sfidës | Titulli i kredencialeve | Pala e përfshirë |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Një proxy ndërmjetës |
| 401 Unauthorized | WWW-Authenticate | Authorization | Rrjedha e autentikimit të burimit të origjinës |
Statusi është një tregues i parë thelbësor, por kontrolloni gjithë shkëmbimin. Numri 407 në tekstin e një faqeje nuk barazohet me përgjigje HTTP 407 reale. Po ashtu, një faqe identifikimi e personalizuar mund të kthejë 200 dhe të kërkojë ende autentikim në shtresën e aplikacionit.
Pse HTTPS mund të dështojë me 407 para se të arrijë sajtin
Kur një proxy HTTP i zakonshëm përcjell HTTPS, klienti zakonisht kërkon fillimisht një tunel CONNECT. Proxy mund të kërkojë autentikim për atë kërkesë CONNECT. Nëse nuk përfundohet, sesioni TLS me destinacionin ende nuk është krijuar përmes tunelit. Ndryshimi i tokenit API të sajtit ka pak gjasa ta rregullojë këtë fazë.
Përdorni dalje të hollësishme për të parë ku shfaqet sfida:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Zëvendësoni dëgjuesin lokal me tuajin dhe lexoni sfidën e parë në regjistër. 407 gjatë CONNECT vjen para TLS-it të destinacionit; një 401 më i vonshëm mund të pasojë një tunel të krijuar me sukses.
Jepini kredencialet përmes ndërfaqes së proxy-t
Për një pikë fundore dhe llogari nga një administrator i besuar, curl mund të negociojë skemën e autentikimit të proxy-t dhe të kërkojë fjalëkalimin e munguar:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Zëvendësoni pikën fundore dhe përdoruesin e shembullit me të dhënat e shërbimit që lejoheni të përdorni. Vetëm përdoruesi shmang vendosjen e fjalëkalimit drejtpërdrejt në komandën sipër. Metodat e mbështetura varen nga ndërtimi i curl dhe proxy; nëse negocimi dështon, kontrolloni sfidën reale dhe aftësitë e ndërtimit.
Opsioni i autentikimit të proxy-t është i ndarë nga ai i përdoruesit të origjinës në curl. Mos shtoni një titull Authorization për origjinën në vend të përgjigjes ndaj sfidës së proxy-t. Mos përcillni manualisht tituj kredencialesh të proxy-t drejt kërkesave të palidhura dhe mos i ruani në tituj të ripërdorur nga gjithë aplikacioni.
Nëse proxy vazhdon të kthejë 407
- Konfirmoni hostin dhe portën e synuar të proxy-t.
- Kontrolloni skemat që njofton proxy në vend që të supozoni Basic.
- Konfirmoni gjendjen e llogarisë dhe formatin e veçantë të përdoruesit nëse kërkohet.
- Kontrolloni kalimin e karaktereve speciale nëse kredencialet janë në URL.
- Përcaktoni nëse autentikimi i ndërmarrjes i integruar me shfletuesin kërkon mbështetje të mjedisit të ekzekutimit ose platformës.
- Nëse të dhënat e klientit nuk mjaftojnë, kërkojini administratorit identifikues kërkese ose regjistër serveri pa të dhëna të ndjeshme.
403 ose CONNECT i refuzuar mund të vijë nga politika e qasjes edhe pas identifikimit të suksesshëm. Më shumë prova fjalëkalimesh nuk japin qasje në një destinacion të ndaluar.
HTTPS i destinacionit nuk mbron çdo shkëmbim kredencialesh të proxy-t
Autentikimi i proxy-t mund të ndodhë para TLS-it të destinacionit. Nëse lidhja me vetë proxy-n nuk është e enkriptuar dhe metoda zbulon aty kredenciale të ripërdorshme, destinacioni HTTPS nuk mbron prapaveprueshëm atë shkëmbim. Zgjidhni transport dhe autentikim të përshtatshëm; mos dërgoni llogari private te një proxy publik i panjohur.
Kontrolloni regjistrat e hollësishëm përpara ndarjes. Edhe kur mjeti maskon fushat e zakonshme, mund të mbeten përdorues, emra pikash të brendshme, cookies apo të dhëna të tjera identifikuese.