Mga username na may domain sa mga kredensyal ng proxy
Ihiwalay ang malabong pangalan ng account sa mga API na may hiwalay na field ng domain, at iwasang baguhin ang pagkakakilanlan ng account para lamang masunod ang sintaks ng URL.
Sinasabi ng isang sagot na alisin ang DOMAIN\. Sinasabi ng isa pa na idagdag ito. Maaaring mali ang dalawang pagbabago para sa iyong proxy.
May dalawang tanong: anong pagkakakilanlan ang inaasahan ng serbisyo, at paano ito kinakatawan ng napiling API.
| Interface | Ano ang dapat itatag |
|---|---|
| Isang field ng pangalan ng account | Ang eksaktong sintaks ng account na tinatanggap ng operator |
| Isang API ng kredensyal na may field ng domain | Kung dapat bang hiwalay na ibigay ang domain at username |
| Mga bahagi ng kredensyal sa loob ng URI | Paano dapat i-encode ang mga nilalayong halaga para sa lalagyang iyon |
Halimbawa, ang .NET ay naglalabas ng constructor na NetworkCredential na may hiwalay na argumento para sa username, password at domain. Ang paglalagay ng domain sa dalawang field nang walang pagkakaiba ay hindi portable na paraan ng pag-configure ng integrated authentication.
Ang Basic authentication ay isa pang kaso: binibigyang-kahulugan ng server ang ibinigay na teksto ng account ayon sa sarili nitong patakaran. Ang pagiging nasa parehong network ay hindi nagpapatunay na may implicit na prefix ng domain. Ni ang isang username na may domain ay hindi awtomatikong ibang protocol ng authentication.
Dapat pangalagaan ng URL escaping ang nilalayong account sa halip na baguhin ito. Ang backslash sa isang string ng pinagmulang wika, ang backslash sa isang pangalan ng account at ang percent-encoded na representasyon nito sa loob ng URI ay magkakahiwalay na antas.
Kunin mula sa operator ang tinatanggap na anyo ng pagkakakilanlan at scheme, pagkatapos ay gamitin ang naaangkop na interface ng kredensyal. Ang random na paghahalili sa pagitan ng maikling pangalan, pangalan ng domain at pangalang mukhang email ay gumagawa ng mahinang ebidensya tungkol sa orihinal na 407.