Tartomány szerint minősített felhasználónevek a proxy hitelesítő adataiban
Különböztesse meg az átláthatatlan fióknevet a külön tartomány mezővel rendelkező API-któl, és kerülje a fiókazonosító módosítását pusztán az URL-szintaxis kedvéért.
Az egyik válasz azt mondja, távolítsa el a DOMAIN\ részt. A másik azt, hogy adja hozzá. Mindkét változtatás hibás lehet a proxyja számára.
Két kérdés van: melyik identitást várja a szolgáltatás, és hogyan ábrázolja ezt az identitást a választott API.
| Interfész | Mit kell tisztázni |
|---|---|
| Egyetlen fióknév mező | Az üzemeltető által elfogadott pontos fiókszintaxis |
| Hitelesítőadat-API tartomány mezővel | A tartományt és a felhasználónevet külön kell-e megadni |
| Hitelesítőadat-összetevők URI-n belül | Hogyan kell a szándékolt értékeket az adott tárolóhoz kódolni |
A .NET például NetworkCredential konstruktort kínál külön felhasználónév-, jelszó- és tartományargumentummal. A tartomány válogatás nélküli két mezőbe helyezése nem hordozható módja az integrált hitelesítés beállításának.
A Basic hitelesítés más eset: a kiszolgáló a megadott fiókszöveget a saját szabályzata szerint értelmezi. Az azonos hálózaton lét nem bizonyítja, hogy a tartomány előtagja implikált. A tartománnyal minősített név sem automatikusan más hitelesítési protokoll.
Az URL-escapelésnek meg kell őriznie a szándékolt fiókot ahelyett, hogy megváltoztatná. A fordított perjel a forrásnyelvi karakterláncban, a fordított perjel a fióknévben és annak százalékos kódolású ábrázolása az URI-n belül külön rétegek.
Szerezze be az elfogadott identitásformát és sémát az üzemeltetőtől, majd használja a megfelelő hitelesítőadat-interfészt. A rövid név, a tartománynév és az e-mail-szerű név közötti véletlenszerű váltogatás gyenge bizonyítékot ad az eredeti 407-ről.