HTTP 407 o 401: aling login ang pumapalya?

Hinihingi ng 407 na mag-authenticate ka sa proxy. Hinihingi ng 401 ang authentication para sa target resource. Maaaring maranasan ng iisang request ang dalawa, kaya alamin muna kung sino ang humihingi bago magbigay ng password.

Ihambing ang status at authentication challenge headers

Mahalagang unang palatandaan ang status, pero suriin ang buong palitan. Ang 407 na nakasulat sa page ay hindi katumbas ng aktuwal na HTTP 407 response. Gayundin, puwedeng magbalik ng 200 ang pasadyang login page at mangailangan pa rin ng authentication sa application layer.

Bakit maaaring pumalya ang HTTPS sa 407 bago makarating sa website

Kapag ordinaryong HTTP proxy ang nagdadala ng HTTPS request, karaniwang humihingi muna ang client ng CONNECT tunnel. Puwedeng hingan ng proxy ng authentication ang CONNECT request na iyon. Kung hindi ito nakumpleto, hindi pa naitatatag ang TLS session sa destinasyon sa loob ng tunnel. Malamang na hindi maaayos ng pagpapalit ng website API token ang yugtong ito.

Gumamit ng verbose output para makita kung saan lumalabas ang challenge:

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

Palitan ang lokal na listener ng sarili mo at basahin ang unang challenge sa log. Nauuna sa destination TLS ang 407 habang CONNECT; puwedeng sumunod ang 401 matapos maitatag nang maayos ang tunnel.

Ibigay ang proxy credentials sa proxy interface

Para sa endpoint at account mula sa administrator na pinagkakatiwalaan mo, puwedeng makipagnegosasyon ang curl sa authentication scheme ng proxy at humingi ng kulang na password:

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

Palitan ang endpoint at username sa halimbawa ng detalye ng serbisyong awtorisado kang gamitin. Username lang ang ibigay para hindi direktang nakasulat ang password sa command sa itaas. Nag-iiba ang suporta ayon sa build ng curl at proxy; kapag pumalya ang negotiation, tingnan ang aktuwal na challenge at kakayahan ng build.

Hiwalay ang proxy authentication option sa origin-user authentication option ng curl. Huwag magdagdag ng origin Authorization header bilang pamalit sa sagot sa proxy challenge. Iwasan ding manu-manong ipasa ang proxy credential headers sa hindi kaugnay na requests o itago ang mga ito sa headers na muling ginagamit sa buong app.

Kung patuloy na nagbabalik ng 407 ang proxy

• Tiyaking tama ang nilalayong proxy host at port.
• Tingnan ang mga scheme na iniaalok ng proxy sa halip na ipagpalagay na Basic.
• Kumpirmahin ang account status at kung may partikular na username format ang serbisyo.
• Suriin ang pagpasa ng special characters kung nasa URL ang credentials.
• Alamin kung nangangailangan ng runtime o platform support ang browser-integrated na enterprise authentication.
• Kung kulang ang ebidensiya sa client, humingi sa administrator ng request identifier o server log entry na inalisan ng sensitibong data.

Ang 403 o denied CONNECT ay maaaring desisyon ng access policy kahit matagumpay ang login. Hindi magbibigay ng access sa bawal na destinasyon ang mas marami pang password attempt.

Hindi pinoprotektahan ng destination HTTPS ang lahat ng proxy credential exchange

Puwedeng mauna ang proxy authentication sa destination TLS. Kung hindi naka-encrypt ang koneksyon sa mismong proxy at inilalantad ng paraan ang reusable credentials doon, hindi mapoprotektahan nang pabalik ng HTTPS target ang naunang palitan. Pumili ng transport at authentication na angkop sa serbisyo; huwag magpadala ng pribadong account sa di-kilalang pampublikong proxy.

Suriin ang verbose logs bago ibahagi. Kahit itago ng tool ang karaniwang credential fields, maaari pa ring may username, pangalan ng internal endpoint, cookie, o ibang impormasyong nagpapakilala.