HTTP 407 au 401: ni uingiaji upi unaoshindwa?
Tofautisha uthibitishaji wa proksi na wa tovuti, kagua vichwa sahihi na usitume taarifa za kuingia kwa upande usiofaa.
407 huomba uthibitishaji kwa proksi. 401 huomba uthibitishaji kwa rasilimali lengwa. Ombi linaweza kukutana na zote mbili, hivyo tambua anayeomba kabla ya kutoa nenosiri.
Linganisha hali na vichwa vya changamoto ya uthibitishaji
| Jibu | Kichwa cha changamoto | Kichwa cha taarifa za kuingia | Upande unaohusika |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Proksi ya kati |
| 401 Unauthorized | WWW-Authenticate | Authorization | Mtiririko wa uthibitishaji wa rasilimali asili |
Hali ni kidokezo cha kwanza muhimu, lakini chunguza ubadilishanaji wote. Nambari 407 katika maandishi ya ukurasa si sawa na jibu halisi la HTTP 407. Vivyo hivyo, ukurasa maalumu wa kuingia unaweza kurudisha 200 na bado kuhitaji uthibitishaji katika safu ya programu.
Kwa nini HTTPS inaweza kushindwa kwa 407 kabla ya kufikia tovuti
Proksi ya kawaida ya HTTP inapobeba ombi la HTTPS, mteja kwa kawaida huomba kwanza handaki la CONNECT. Proksi inaweza kuomba uthibitishaji wa ombi hilo la CONNECT. Usipokamilika, kipindi cha TLS na lengwa bado hakijaanzishwa kupitia handaki. Kubadilisha tokeni ya API ya tovuti kwa hiyo huenda kusirekebishe hatua hii.
Tumia matokeo ya kina kuona changamoto inapotokea:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Badilisha sehemu ya ndani ya kupokea miunganisho na yako, kisha soma changamoto ya kwanza kwenye kumbukumbu. 407 wakati wa CONNECT hutangulia TLS ya lengwa; 401 ya baadaye inaweza kufuata handaki lililoanzishwa vizuri.
Toa taarifa za proksi kupitia kiolesura cha proksi
Kwa sehemu ya mwisho na akaunti kutoka kwa msimamizi unayemwamini, curl inaweza kujadiliana mpango wa uthibitishaji na kuomba nenosiri ambalo halijatolewa:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Badilisha sehemu ya mwisho na mtumiaji wa mfano kwa taarifa za huduma unayoruhusiwa kutumia. Kutaja mtumiaji pekee huepusha nenosiri moja kwa moja katika amri iliyo juu. Mbinu zinazotumika hutofautiana kwa toleo lililojengwa la curl na proksi; mazungumzo yakishindwa, angalia changamoto halisi na uwezo wa toleo hilo.
Chaguo la uthibitishaji wa proksi ni tofauti na uthibitishaji wa mtumiaji kwa seva asili katika curl. Usiongeze kichwa cha Authorization cha asili badala ya jibu kwa changamoto ya proksi. Pia usipitishe kwa mkono vichwa vya taarifa za proksi kwa maombi yasiyohusika au kuvihifadhi katika vichwa vinavyotumika tena katika programu nzima.
Proksi ikiendelea kurudisha 407
- Thibitisha kwamba unatumia mwenyeji na porti iliyokusudiwa ya proksi.
- Kagua mipango inayotangazwa na proksi badala ya kudhani Basic.
- Thibitisha hali ya akaunti na namna maalumu ya jina la mtumiaji ikiwa inahitajika.
- Kagua upitishaji wa herufi maalumu ikiwa taarifa zimo katika URL.
- Amua kama uthibitishaji wa kampuni uliounganishwa na kivinjari unahitaji usaidizi wa mazingira ya kuendesha programu au jukwaa.
- Ushahidi wa mteja usipotosha, mwombe msimamizi kitambulisho cha ombi au ingizo la kumbukumbu ya seva lililoondolewa taarifa nyeti.
403 au CONNECT iliyokataliwa inaweza kuwa uamuzi wa sera ya ufikiaji hata baada ya kuingia vizuri. Kujaribu manenosiri zaidi hakutatoa ufikiaji wa lengwa lililokatazwa.
HTTPS ya lengwa hailindi kila ubadilishanaji wa taarifa za proksi
Uthibitishaji wa proksi unaweza kutokea kabla ya TLS ya lengwa. Muunganisho kwa proksi yenyewe usiposimbwa na mbinu ikifichua taarifa zinazoweza kutumiwa tena kwenye njia hiyo, lengwa la HTTPS halilindi ubadilishanaji huo uliopita kwa kurudi nyuma. Chagua usafirishaji na uthibitishaji unaofaa huduma; usitume akaunti binafsi kwa proksi ya umma usiyoijua.
Kagua kumbukumbu za kina kabla ya kuzishiriki. Hata zana ikificha sehemu za kawaida za kuingia, zinaweza kubaki na majina ya watumiaji, majina ya sehemu za mwisho za ndani, vidakuzi au data nyingine ya utambulisho.