HTTP 407 atau 401: log masuk yang mana gagal?
Bezakan pengesahan proksi daripada pengesahan laman, semak pengepala yang betul dan jangan hantar kelayakan kepada pihak yang salah.
407 meminta pengesahan pada proksi. 401 meminta pengesahan untuk sumber sasaran. Satu permintaan boleh menemui kedua-duanya, jadi tentukan siapa yang meminta sebelum memberikan kata laluan.
Bandingkan status dan pengepala cabaran pengesahan
| Respons | Pengepala cabaran | Pengepala kelayakan | Pihak terlibat |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Proksi perantara |
| 401 Unauthorized | WWW-Authenticate | Authorization | Aliran pengesahan sumber asal |
Status ialah petunjuk awal yang penting, tetapi semak seluruh pertukaran. Nombor 407 dalam teks halaman tidak sama dengan respons HTTP 407 sebenar. Halaman log masuk tersuai juga boleh memulangkan 200 sambil masih memerlukan pengesahan pada lapisan aplikasi.
Mengapa HTTPS boleh gagal dengan 407 sebelum sampai ke laman
Apabila proksi HTTP biasa membawa permintaan HTTPS, klien lazimnya meminta terowong CONNECT terlebih dahulu. Proksi boleh meminta pengesahan bagi permintaan CONNECT itu. Jika belum selesai, sesi TLS dengan destinasi belum diwujudkan melalui terowong. Menukar token API laman mungkin tidak membaiki peringkat ini.
Gunakan output terperinci untuk melihat tempat cabaran muncul:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Gantikan pendengar setempat dengan milik anda dan baca cabaran pertama dalam log. 407 semasa CONNECT mendahului TLS destinasi; 401 kemudian boleh menyusul selepas terowong berjaya diwujudkan.
Berikan kelayakan melalui antara muka proksi
Untuk titik akhir dan akaun daripada pentadbir yang dipercayai, curl boleh merundingkan skim pengesahan proksi dan meminta kata laluan yang belum diberi:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Gantikan titik akhir serta pengguna contoh dengan butiran perkhidmatan yang anda dibenarkan gunakan. Menyatakan pengguna sahaja mengelakkan kata laluan terus dalam arahan di atas. Kaedah yang disokong berbeza mengikut binaan curl dan proksi; jika rundingan gagal, semak cabaran sebenar serta keupayaan binaan.
Pilihan pengesahan proksi berasingan daripada pengesahan pengguna pelayan asal dalam curl. Jangan tambah pengepala Authorization asal sebagai ganti jawapan kepada cabaran proksi. Jangan juga menghantar pengepala kelayakan proksi secara manual kepada permintaan tidak berkaitan atau menyimpannya dalam pengepala yang diguna semula oleh seluruh aplikasi.
Jika proksi terus memulangkan 407
- Sahkan hos dan port proksi yang dikehendaki digunakan.
- Semak skim yang diiklankan proksi, bukan terus menganggap Basic.
- Sahkan status akaun dan format nama pengguna khusus yang mungkin diperlukan.
- Semak penghantaran aksara khas jika kelayakan berada dalam URL.
- Tentukan sama ada pengesahan syarikat yang bersepadu dengan pelayar memerlukan sokongan masa jalan atau platform.
- Jika bukti klien tidak mencukupi, minta pengecam permintaan atau entri log pelayan yang telah dibersihkan daripada data sensitif daripada pentadbir.
403 atau CONNECT ditolak boleh menjadi keputusan dasar akses walaupun log masuk berjaya. Lebih banyak cubaan kata laluan tidak memberikan akses ke destinasi terlarang.
HTTPS destinasi tidak melindungi setiap pertukaran kelayakan proksi
Pengesahan proksi boleh berlaku sebelum TLS destinasi diwujudkan. Jika sambungan kepada proksi sendiri tidak disulitkan dan kaedah itu mendedahkan kelayakan boleh guna semula pada laluan tersebut, destinasi HTTPS tidak melindungi pertukaran terdahulu secara retroaktif. Pilih pengangkutan dan pengesahan yang sesuai; jangan hantar akaun peribadi kepada proksi awam yang tidak dikenali.
Semak log terperinci sebelum berkongsi. Walaupun alat menutup medan kelayakan biasa, nama pengguna, nama titik akhir dalaman, kuki atau data pengenalan lain mungkin masih ada.