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 эсвэл бусад таних өгөгдөл үлдэж болно.