Nama pengguna berkualifikasi domain dalam kredensial proxy
Bedakan nama akun buram dari API dengan bidang domain terpisah, dan hindari mengubah identitas akun hanya demi memenuhi sintaksis URL.
Satu jawaban mengatakan hapus DOMAIN\. Jawaban lain mengatakan tambahkan. Kedua perubahan bisa salah untuk proxy Anda.
Ada dua pertanyaan: identitas mana yang diharapkan layanan, dan bagaimana API yang dipilih merepresentasikan identitas itu.
| Antarmuka | Apa yang harus dipastikan |
|---|---|
| Satu bidang nama akun | Sintaksis akun persis yang diterima operator |
| API kredensial dengan bidang domain | Apakah domain dan nama pengguna harus diberikan terpisah |
| Komponen kredensial di dalam URI | Bagaimana nilai yang dimaksud harus dikodekan untuk wadah itu |
Contohnya, .NET menyediakan konstruktor NetworkCredential dengan argumen nama pengguna, kata sandi, dan domain yang terpisah. Menaruh domain di dua bidang tanpa membedakan bukan cara portabel untuk mengonfigurasi autentikasi terintegrasi.
Autentikasi Basic adalah kasus lain: server menafsirkan teks akun yang diberikan menurut kebijakannya sendiri. Berada di jaringan yang sama tidak membuktikan bahwa prefiks domain tersirat. Nama berkualifikasi domain juga bukan otomatis protokol autentikasi yang berbeda.
Escaping URL harus mempertahankan akun yang dimaksud alih-alih mengubahnya. Garis miring terbalik dalam string bahasa sumber, garis miring terbalik dalam nama akun, dan representasinya yang dikodekan persen di dalam URI adalah lapisan terpisah.
Dapatkan bentuk identitas dan skema yang diterima dari operator, lalu gunakan antarmuka kredensial yang sesuai. Berganti-ganti secara acak antara nama pendek, nama domain, dan nama mirip email menghasilkan bukti lemah tentang 407 asli.