HTTP 407 թե 401․ ո՞ր մուտքն է ձախողվում
Տարբերեք պրոքսիի և կայքի նույնականացումը, ստուգեք ճիշտ վերնագրերը և մուտքի տվյալները սխալ կողմին մի ուղարկեք։
407-ը պահանջում է նույնականացում պրոքսիում։ 401-ը պահանջում է նույնականացում նպատակային ռեսուրսի համար։ Մի հարցումը կարող է հանդիպել երկուսին էլ․ գաղտնաբառ տալուց առաջ պարզեք, թե ով է պահանջում։
Համեմատեք կարգավիճակը և նույնականացման պահանջի վերնագրերը
| Պատասխան | Նույնականացման պահանջի վերնագիր | Մուտքի տվյալների վերնագիր | Մասնակից |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Միջանկյալ պրոքսի |
| 401 Unauthorized | WWW-Authenticate | Authorization | Սկզբնական ռեսուրսի նույնականացման ընթացքը |
Կարգավիճակը կարևոր առաջին հուշում է, բայց դիտեք ամբողջ փոխանակումը։ Էջի տեքստում 407 թիվը իրական HTTP 407 պատասխան չէ։ Նմանապես, հատուկ մուտքի էջը կարող է վերադարձնել 200 և դեռ նույնականացում պահանջել կիրառական շերտում։
Ինչո՞ւ HTTPS-ը կարող է 407-ով ձախողվել դեռ կայքին չհասած
Երբ սովորական HTTP պրոքսին փոխանցում է HTTPS հարցում, հաճախորդը սովորաբար նախ խնդրում է ստեղծել CONNECT թունել։ Պրոքսին կարող է նույնականացում պահանջել այդ CONNECT հարցման համար։ Եթե այն չի ավարտվել, նպատակային TLS նստաշրջանը թունելով դեռ հաստատված չէ։ Կայքի API թոքենը փոխելը դժվար թե շտկի այս փուլը։
Օգտագործեք մանրամասն ելք՝ տեսնելու, թե պահանջը որտեղ է հայտնվում․
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Տեղային լսող հանգույցը փոխարինեք ձերով և մատյանում կարդացեք առաջին պահանջը։ CONNECT-ի ընթացքում 407-ը նպատակային TLS-ից առաջ է․ ավելի ուշ 401-ը կարող է հայտնվել հաջող հաստատված թունելից հետո։
Պրոքսիի տվյալները փոխանցեք պրոքսիի միջերեսով
Վստահելի ադմինիստրատորի տրամադրած վերջնակետի ու հաշվի համար curl-ը կարող է համաձայնեցնել պրոքսիի նույնականացման եղանակը և հարցնել չնշված գաղտնաբառը․
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Օրինակի վերջնակետն ու օգտատիրոջը փոխարինեք թույլատրված ծառայության տվյալներով։ Միայն օգտատիրոջ անունը նշելը խուսափում է գաղտնաբառը անմիջապես վերևի հրամանում գրելուց։ Մեթոդների աջակցությունը կախված է curl-ի կառուցվածքից ու պրոքսիից․ համաձայնեցման ձախողման դեպքում ստուգեք իրական պահանջն ու կառուցվածքի հնարավորությունները։
Պրոքսիի նույնականացման ընտրանքը առանձին է curl-ի սկզբնական սերվերի օգտատիրոջ նույնականացումից։ Մի ավելացրեք սկզբնական սերվերի Authorization վերնագիրը՝ պրոքսիի պահանջին պատասխանելու փոխարեն։ Պրոքսիի տվյալների վերնագրերը ձեռքով մի փոխանցեք անկապ հարցումների և մի պահեք ամբողջ ծրագրում կրկին օգտագործվող վերնագրերում։
Եթե պրոքսին անընդհատ 407 է վերադարձնում
- Համոզվեք, որ օգտագործում եք նախատեսված պրոքսիի հոսթն ու պորտը։
- Ստուգեք պրոքսիի հայտարարած եղանակները՝ Basic ենթադրելու փոխարեն։
- Ստուգեք հաշվի վիճակը և ծառայության պահանջած օգտատիրոջ անվան ձևաչափը։
- Ստուգեք հատուկ նիշերի փոխանցումը, եթե տվյալները URL-ում են։
- Պարզեք՝ դիտարկչին ինտեգրված կազմակերպության նույնականացումը պահանջո՞ւմ է կատարման միջավայրի կամ հարթակի աջակցություն։
- Եթե հաճախորդի տվյալները բավարար չեն, ադմինիստրատորից խնդրեք հարցման նույնացուցիչ կամ սերվերի մատյանի գրառում՝ զգայուն տվյալները հեռացված։
403-ը կամ մերժված CONNECT-ը կարող է հասանելիության քաղաքականության որոշում լինել նույնիսկ հաջող մուտքից հետո։ Նոր գաղտնաբառերի փորձերը մուտք չեն տա արգելված նպատակակետ։
Նպատակային HTTPS-ը չի պաշտպանում պրոքսիի մուտքի տվյալների ամեն փոխանակում
Պրոքսիի նույնականացումը կարող է լինել նպատակային TLS-ից առաջ։ Եթե հենց պրոքսիին միացումը չգաղտնագրված է, և եղանակն այնտեղ բացահայտում է կրկին օգտագործելի տվյալներ, HTTPS նպատակակետը նախկին փոխանակումը հետադարձ կերպով չի պաշտպանում։ Ընտրեք ծառայությանը հարմար փոխանցում և նույնականացում․ անձնական հաշիվներ մի ուղարկեք անծանոթ հանրային պրոքսիին։
Մանրամասն մատյանները կիսելուց առաջ ստուգեք։ Նույնիսկ եթե գործիքը թաքցնում է սովորական մուտքի դաշտերը, կարող են մնալ օգտատերերի անուններ, ներքին վերջնակետերի անուններ, cookie-ներ կամ նույնականացնող այլ տվյալներ։