Domajn-kvalifikitaj uzantnomoj en prokurilaj akreditiloj
Distingi neklaran kontan nomon disde API-oj kun apartaj domajnaj kampoj, kaj eviti ŝanĝi kontan identecon nur por kontentigi URL-sintakson.
Unu respondo diras forigi DOMAIN\. Alia diras aldoni ĝin. Ambaŭ ŝanĝoj povas esti malĝustaj por via prokurilo.
Estas du demandoj: kiun identecon la servo atendas, kaj kiel la elektita API reprezentas tiun identecon.
| Interfaco | Kion konstati |
|---|---|
| Unu sola kontnoma kampo | La ĝusta konta sintakso, kiun la operatoro akceptas |
| Akreditila API kun domajna kampo | Ĉu domajno kaj uzantnomo estu donitaj aparte |
| Akreditilaj komponantoj ene de URI | Kiel la celitaj valoroj estu koditaj por tiu ujo |
Ekzemple, .NET elmetas konstruilon NetworkCredential kun apartaj argumentoj por uzantnomo, pasvorto kaj domajno. Meti domajnon en du kampojn sen distingo ne estas portebla maniero agordi integritan aŭtentikigon.
Baza aŭtentikigo estas alia kazo: la servilo interpretas la donitan kontan tekston laŭ sia propra politiko. Esti en la sama reto ne pruvas, ke domajna prefikso estas implicita. Nek domajn-kvalifikita nomo estas aŭtomate alia aŭtentikiga protokolo.
URL-escaping devus konservi la celitan konton anstataŭ ŝanĝi ĝin. Dekstra klino en ĉeno de fonta lingvo, dekstra klino en konta nomo kaj ĝia procente kodita reprezento ene de URI estas apartaj tavoloj.
Akiru la akceptitan identecformon kaj skemon ĉe la operatoro, poste uzu la respondan akreditilan interfacon. Hazarde alterni inter mallonga nomo, domajna nomo kaj retpoŝteca nomo kreas malfortan pruvon pri la origina 407.