Uporabniška imena s domeno v proxy poverilnicah
Razlikujte neprozorno ime računa od API-jev z ločenimi polji domene in se izogibajte spreminjanju identitete računa zgolj zaradi skladnje URL.
En odgovor pravi, da odstranite DOMAIN\. Drugi pravi, da ga dodate. Obe spremembi sta lahko za vaš proxy napačni.
Obstajata dve vprašanji: katero identiteto storitev pričakuje in kako izbrani API to identiteto predstavlja.
| Vmesnik | Kaj je treba ugotoviti |
|---|---|
| Eno polje imena računa | Natančna skladnja računa, ki jo operater sprejme |
| API poverilnic s poljem domene | Ali je treba domeno in uporabniško ime navesti ločeno |
| Sestavni deli poverilnic v URI | Kako je treba predvidene vrednosti kodirati za ta vsebnik |
Na primer, .NET ponuja konstruktor NetworkCredential z ločenimi argumenti za uporabniško ime, geslo in domeno. Postavljanje domene v dve polji brez razlikovanja ni prenosljiv način za konfiguriranje integrirane avtentikacije.
Osnovna avtentikacija je drug primer: strežnik razlaga poslano besedilo računa po svoji politiki. Bivanje v istem omrežju ne dokazuje, da je predpona domene implicitna. Tudi ime z domeno ni samodejno drug protokol avtentikacije.
Escapiranje URL bi moralo ohraniti predvideni račun, ne pa ga spremeniti. Povratna poševnica v nizu izvornega jezika, povratna poševnica v imenu računa in njena odstotna kodiranost v URI so ločene plasti.
Pridobite sprejeto obliko identitete in shemo pri operaterju, nato uporabite ustrezen vmesnik poverilnic. Naključno izmenjavanje kratkega imena, domenskega imena in imena, podobnega e-pošti, daje šibke dokaze o izvirnem 407.