HTTP 407 of 401: hokker oanmelding mislearret?
Skied proxy- en webside-autentikaasje, besjoch de goede kopteksten en stjoer oanmeldgegevens net nei de ferkearde partij.
407 freget autentikaasje by de proxy. 401 freget autentikaasje foar de doelboarne. Ien fersyk kin beide tsjinkomme; fyn dus út wa’t freget foar’tsto in wachtwurd joust.
Fergelykje de status en kopteksten fan de autentikaasje-útdaging
| Antwurd | Útdagingskoptekst | Koptekst mei oanmeldgegevens | Belutsen partij |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | In tuskenlizzende proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | De autentikaasjestream fan de oarspronklike boarne |
De status is in wichtige earste oanwizing, mar besjoch de hiele útwikseling. In side mei 407 yn de tekst is gjin echt HTTP 407-antwurd. In eigen oanmeldside kin ek 200 weromjaan en dochs autentikaasje op tapassingsnivo freegje.
Wêrom HTTPS al foar de webside mei 407 mislearje kin
As in gewoane HTTP-proxy in HTTPS-fersyk ferfiert, freget de kliïnt ornaris earst in CONNECT-tunnel. De proxy kin autentikaasje foar dat CONNECT-fersyk freegje. As dy net foltôge is, is de TLS-sesje mei it doel noch net troch de tunnel oprjochte. It API-token fan de webside feroarje sil dy faze dêrom wierskynlik net reparearje.
Brûk detaillearre útfier om te sjen wêr’t de útdaging komt:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Ferfang de lokale listener troch dyn eigen en lês de earste útdaging yn it log. In 407 ûnder CONNECT komt foar doel-TLS; in lettere 401 kin nei in slagge tunnel komme.
Jou proxygegevens troch de proxy-ynterface
Foar in einpunt en akkount fan in behearder dy’tsto fertroust, kin curl it autentikaasjeskema ûnderhannelje en in ûntbrekkend wachtwurd freegje:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Ferfang it foarbyldeinpunt en de brûker troch gegevens fan de tsjinst dy’tsto brûke meist. Allinnich de brûker opjaan foarkomt it wachtwurd streekrjocht yn it boppesteande kommando. Stipe metoaden ferskille mei de curl-bou en proxy; kontrolearje de echte útdaging en mooglikheden fan de bou as ûnderhanneling mislearret.
De proxy-autentikaasje-opsje stiet los fan curls brûkersautentikaasje by de oarspronklike tsjinner. Foegje gjin Authorization-koptekst foar de oarsprong ta ynstee fan in antwurd op de proxy-útdaging. Stjoer proxygegevenskopteksten ek net mei de hân nei net-relatearre fersiken en bewarje se net yn kopteksten dy’t de hiele tapassing opnij brûkt.
As de proxy 407 weromjaan bliuwt
- Befêstigje datst de bedoelde proxyhost en poarte brûkst.
- Kontrolearje de oanbeane skema’s ynstee fan Basic oan te nimmen.
- Kontrolearje de akkountstatus en in spesifyk brûkersnammeformaat dat de tsjinst freget.
- Kontrolearje it trochjaan fan spesjale tekens as de gegevens yn in URL steane.
- Bepaal oft bedriuwsautentikaasje yn de browser stipe fan de runtime of it platfoarm nedich hat.
- Freegje de behearder om in fersyk-ID of tsjinnerlogregel sûnder gefoelige gegevens as kliïntbewizen net genôch binne.
In 403 of wegere CONNECT kin ek nei slagge oanmelding in tagongsbeliedsbeslút wêze. Mear wachtwurdpogingen jouwe gjin tagong ta in ferbean doel.
HTTPS fan it doel beskermet net elke útwikseling fan proxygegevens
Proxy-autentikaasje kin foar it oprjochtsjen fan doel-TLS barre. As de ferbining mei de proxy sels net fersifere is en de metoade dêr werbrûkbere gegevens bleatleit, beskermet in HTTPS-doel de eardere útwikseling net efterôf. Kies by de tsjinst passende transport en autentikaasje; stjoer gjin privee-akkounts nei in ûnbekende iepenbiere proxy.
Kontrolearje detaillearre logs foar’tsto se dielst. Ek as it ark gewoane oanmeldfjilden ferberget, kinne der brûkersnammen, ynterne einpuntnammen, koekjes of oare identifisearjende gegevens yn stean.