Nume de utilizator calificate cu domeniu în acreditările proxy
Distingeți un nume de cont opac de API-urile cu câmpuri de domeniu separate și evitați schimbarea identității unui cont doar pentru a satisface sintaxa URL.
Un răspuns spune să eliminați DOMAIN\. Altul spune să îl adăugați. Ambele modificări pot fi greșite pentru proxy-ul dvs.
Există două întrebări: ce identitate așteaptă serviciul și cum reprezintă API-ul ales această identitate.
| Interfață | Ce trebuie stabilit |
|---|---|
| Un singur câmp de nume de cont | Sintaxa exactă a contului acceptată de operator |
| Un API de acreditări cu câmp de domeniu | Dacă domeniul și numele de utilizator trebuie furnizate separat |
| Componente de acreditări într-un URI | Cum trebuie codificate valorile dorite pentru acel container |
De exemplu, .NET expune un constructor NetworkCredential cu argumente separate pentru nume de utilizator, parolă și domeniu. Plasarea unui domeniu în două câmpuri fără discernământ nu este o modalitate portabilă de a configura autentificarea integrată.
Autentificarea Basic este un alt caz: serverul interpretează textul contului furnizat conform propriei politici. Faptul că vă aflați în aceeași rețea nu dovedește că un prefix de domeniu este implicit. Nici un nume calificat cu domeniu nu este automat un alt protocol de autentificare.
Escaparea URL ar trebui să păstreze contul dorit în loc să îl schimbe. O bară oblică inversă într-un șir al limbajului sursă, o bară oblică inversă într-un nume de cont și reprezentarea sa codificată procentual într-un URI sunt straturi separate.
Obțineți de la operator forma de identitate și schema acceptate, apoi utilizați interfața de acreditări corespunzătoare. Alternarea aleatorie între un nume scurt, un nume de domeniu și un nume asemănător unei adrese de e-mail produce dovezi slabe despre 407-ul original.