HTTP 407 atau 401: login mana yang gagal?
Bedakan autentikasi proxy dan situs, periksa header yang tepat, dan hindari mengirim kredensial ke pihak yang salah.
407 meminta autentikasi ke proxy. 401 meminta autentikasi untuk sumber daya tujuan. Satu permintaan bisa menemui keduanya, jadi tentukan siapa yang meminta sebelum memberikan kata sandi.
Bandingkan status dan header tantangan autentikasi
| Respons | Header tantangan | Header kredensial | Pihak terkait |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Proxy perantara |
| 401 Unauthorized | WWW-Authenticate | Authorization | Alur autentikasi sumber daya asal |
Status merupakan petunjuk awal yang penting, tetapi periksa seluruh pertukaran. Angka 407 dalam teks halaman tidak sama dengan respons HTTP 407 yang sebenarnya. Halaman login khusus juga dapat mengembalikan 200 sambil tetap meminta autentikasi pada lapisan aplikasi.
Mengapa HTTPS bisa gagal dengan 407 sebelum mencapai situs
Saat proxy HTTP biasa membawa permintaan HTTPS, klien umumnya lebih dulu meminta terowongan CONNECT. Proxy dapat meminta autentikasi atas permintaan CONNECT itu. Jika belum selesai, sesi TLS dengan tujuan belum terbentuk melalui terowongan. Mengganti token API situs kemungkinan tidak memperbaiki tahap tersebut.
Gunakan keluaran rinci untuk melihat lokasi tantangan autentikasi:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Ganti listener lokal dengan milik Anda dan baca tantangan pertama dalam log. 407 selama CONNECT terjadi sebelum TLS tujuan; 401 berikutnya bisa muncul setelah terowongan berhasil dibentuk.
Berikan kredensial melalui antarmuka proxy
Untuk endpoint dan akun dari administrator tepercaya, curl dapat menegosiasikan skema autentikasi proxy dan meminta kata sandi yang belum diberikan:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Ganti endpoint dan pengguna contoh dengan detail layanan yang boleh Anda gunakan. Menyebutkan pengguna saja menghindari kata sandi langsung dalam perintah di atas. Metode yang didukung dapat berbeda menurut build curl dan proxy; bila negosiasi gagal, periksa tantangan yang sebenarnya serta kemampuan build.
Opsi autentikasi proxy terpisah dari opsi autentikasi pengguna server asal dalam curl. Jangan menambahkan header Authorization untuk asal sebagai pengganti jawaban terhadap tantangan proxy. Hindari pula meneruskan header kredensial proxy secara manual ke permintaan yang tidak terkait atau menyimpannya dalam header yang dipakai ulang di seluruh aplikasi.
Jika proxy terus mengembalikan 407
- Pastikan Anda memakai host dan port proxy yang dimaksud.
- Periksa skema yang ditawarkan proxy, jangan langsung menganggap Basic.
- Pastikan status akun dan apakah layanan meminta format pengguna tertentu.
- Periksa pengiriman karakter khusus bila kredensial berada dalam URL.
- Tentukan apakah autentikasi perusahaan yang terintegrasi dengan peramban memerlukan dukungan runtime atau platform.
- Jika bukti klien tidak cukup, mintalah pengenal permintaan atau entri log server yang sudah dibersihkan dari data sensitif kepada administrator.
403 atau CONNECT yang ditolak bisa merupakan keputusan kebijakan akses meskipun login berhasil. Lebih banyak percobaan kata sandi tidak memberikan akses ke tujuan terlarang.
HTTPS tujuan tidak melindungi setiap pertukaran kredensial proxy
Autentikasi proxy dapat berlangsung sebelum TLS tujuan terbentuk. Jika koneksi ke proxy sendiri tidak terenkripsi dan metode tersebut memaparkan kredensial yang bisa dipakai ulang pada jalur itu, tujuan HTTPS tidak melindungi pertukaran sebelumnya secara retroaktif. Pilih transport dan pengaturan autentikasi yang sesuai; jangan kirim akun pribadi ke proxy publik yang tidak dikenal.
Periksa log rinci sebelum membagikannya. Meskipun alat menutupi kolom kredensial umum, log masih bisa memuat nama pengguna, nama endpoint internal, cookie, atau data pengenal lainnya.