HTTP 407 of 401: watter aanmelding misluk?
Onderskei proxyverifikasie van webwerfverifikasie, kyk na die regte kopskrifte en stuur aanmeldbesonderhede na die regte party.
407 vra dat jy by die proxy verifieer. 401 vra verifikasie vir die teikenhulpbron. Een versoek kan albei teëkom; vind dus uit wie vra voordat jy ’n wagwoord gee.
Vergelyk die status en verifikasie-uitdagingskopskrifte
| Antwoord | Uitdagingskopskrif | Aanmeldbesonderhedekopskrif | Betrokke party |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | ’n Tussengangerproxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Die oorspronghulpbron se verifikasievloei |
Die status is ’n belangrike eerste leidraad, maar ondersoek die hele uitruiling. ’n Bladsy met 407 in die teks is nie ’n werklike HTTP 407-antwoord nie. ’n Pasgemaakte aanmeldbladsy kan eweneens 200 teruggee en steeds verifikasie op toepassingsvlak vereis.
Waarom HTTPS reeds voor die webwerf met 407 kan misluk
Wanneer ’n gewone HTTP-proxy ’n HTTPS-versoek dra, vra die kliënt gewoonlik eers vir ’n CONNECT-tonnel. Die proxy kan verifikasie vir daardie CONNECT-versoek vereis. As dit nie voltooi is nie, is die bestemming se TLS-sessie nog nie deur die tonnel gevestig nie. ’n Ander API-token vir die webwerf sal waarskynlik nie dié fase herstel nie.
Gebruik ’n versoek met volledige uitvoer om te sien waar die uitdaging verskyn:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Vervang die plaaslike luisterpunt met joune en lees die eerste uitdaging in die log. ’n 407 tydens CONNECT kom voor die bestemming se TLS; ’n latere 401 kan ná ’n suksesvol gevestigde tonnel volg.
Gee proxybesonderhede deur die proxykoppelvlak
Vir ’n eindpunt en rekening van ’n administrateur wat jy vertrou, kan curl die proxy se verifikasieskema onderhandel en ’n ontbrekende wagwoord vra:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Vervang die voorbeeldeindpunt en gebruiker met die besonderhede van die diens wat jy mag gebruik. Slegs ’n gebruikersnaam vermy die wagwoord direk in die opdrag hier bo. Ondersteunde metodes kan met die curl-bou en proxy verskil; kyk na die werklike uitdaging en bou se vermoëns as onderhandeling misluk.
Die proxyverifikasie-opsie is apart van curl se gebruikersverifikasie by die oorsprong. Moenie ’n oorsprong-Authorization-kopskrif byvoeg in plaas van die antwoord op ’n proxy-uitdaging nie. Moet ook nie proxybesonderhedekopskrifte handmatig na onverwante versoeke stuur of in kopskrifte stoor wat die hele toepassing hergebruik nie.
As die proxy aanhou om 407 terug te gee
- Bevestig dat jy die bedoelde proxygasheer en poort gebruik.
- Kyk na die proxy se geadverteerde skemas eerder as om Basic aan te neem.
- Bevestig die rekeningstatus en enige vereiste gebruikersnaamformaat.
- Kontroleer die oordrag van spesiale karakters as besonderhede in ’n URL ingebed is.
- Bepaal of blaaiergeïntegreerde ondernemingsverifikasie ondersteuning van die looptyd of platform vereis.
- Vra die administrateur vir ’n versoek-ID of bedienerloginskrywing met sensitiewe data verwyder wanneer kliëntbewyse nie genoeg is nie.
’n 403 of geweierde CONNECT kan ’n toegangsbeleidsbesluit wees, selfs ná suksesvolle aanmelding. Meer wagwoordpogings gee nie toegang tot ’n verbode bestemming nie.
Die bestemming se HTTPS beskerm nie elke proxybesonderhede-uitruiling nie
Proxyverifikasie kan gebeur voordat die bestemming se TLS gevestig is. As die verbinding na die proxy self ongeënkripteer is en die metode herbruikbare besonderhede daar blootlê, beskerm ’n HTTPS-bestemming nie die vorige uitruiling agterna nie. Kies ’n gepaste vervoer en verifikasiereëling vir die diens; moenie private rekeninge na ’n onbekende openbare proxy stuur nie.
Gaan volledige logs na voordat jy hulle deel. Selfs al verberg die hulpmiddel algemene aanmeldvelde, kan gebruikersname, interne eindpuntname, koekies of ander identifiserende data oorbly.