Nazwy użytkowników z domeną w danych uwierzytelniających proxy
Odróżnij nieprzejrzystą nazwę konta od interfejsów API z osobnymi polami domeny i unikaj zmiany tożsamości konta wyłącznie po to, by spełnić składnię adresu URL.
Jedna odpowiedź mówi, aby usunąć DOMAIN\. Inna mówi, aby go dodać. Obie zmiany mogą być błędne dla Twojego proxy.
Są dwa pytania: jakiej tożsamości oczekuje usługa i jak wybrane API tę tożsamość reprezentuje.
| Interfejs | Co ustalić |
|---|---|
| Jedno pole nazwy konta | Dokładna składnia konta akceptowana przez operatora |
| API danych uwierzytelniających z polem domeny | Czy domena i nazwa użytkownika mają być podawane osobno |
| Składniki danych uwierzytelniających w URI | Jak zamierzone wartości mają być zakodowane dla tego kontenera |
Na przykład .NET udostępnia konstruktor NetworkCredential z osobnymi argumentami nazwy użytkownika, hasła i domeny. Umieszczanie domeny w dwóch polach bez rozróżnienia nie jest przenośnym sposobem konfigurowania uwierzytelniania zintegrowanego.
Uwierzytelnianie Basic to inny przypadek: serwer interpretuje dostarczony tekst konta według własnej polityki. Przebywanie w tej samej sieci nie dowodzi, że prefiks domeny jest domyślny. Nazwa z domeną też nie jest automatycznie innym protokołem uwierzytelniania.
Escapowanie adresu URL powinno zachować zamierzone konto, a nie je zmieniać. Ukośnik wsteczny w łańcuchu języka źródłowego, ukośnik wsteczny w nazwie konta i jego kodowanie procentowe wewnątrz URI to odrębne warstwy.
Uzyskaj od operatora akceptowaną formę tożsamości i schemat, a następnie użyj odpowiedniego interfejsu danych uwierzytelniających. Losowe przełączanie między krótką nazwą, nazwą domenową i nazwą przypominającą adres e-mail daje słabe dowody w sprawie pierwotnego 407.