Domänenqualifizierte Benutzernamen in Proxy-Anmeldedaten
Unterscheiden Sie einen undurchsichtigen Kontonamen von APIs mit getrennten Domänenfeldern, und vermeiden Sie es, eine Kontoidentität nur wegen der URL-Syntax zu ändern.
Eine Antwort sagt, man solle DOMAIN\ entfernen. Eine andere sagt, man solle es hinzufügen. Beide Änderungen können für Ihren Proxy falsch sein.
Es gibt zwei Fragen: Welche Identität der Dienst erwartet und wie die gewählte API diese Identität darstellt.
| Schnittstelle | Was zu klären ist |
|---|---|
| Ein einzelnes Kontonamenfeld | Die genaue Kontosyntax, die der Betreiber akzeptiert |
| Eine Anmeldedaten-API mit Domänenfeld | Ob Domäne und Benutzername getrennt anzugeben sind |
| Anmeldedaten-Komponenten innerhalb einer URI | Wie die beabsichtigten Werte für diesen Container kodiert werden müssen |
Beispielsweise stellt .NET einen NetworkCredential-Konstruktor mit getrennten Argumenten für Benutzername, Kennwort und Domäne bereit. Eine Domäne unterschiedslos in zwei Felder zu setzen, ist kein portabler Weg, integrierte Authentifizierung zu konfigurieren.
Basic-Authentifizierung ist ein anderer Fall: Der Server interpretiert den übergebenen Kontotext nach seiner eigenen Richtlinie. Im selben Netzwerk zu sein, beweist nicht, dass ein Domänenpräfix impliziert wird. Ein domänenqualifizierter Name ist auch nicht automatisch ein anderes Authentifizierungsprotokoll.
URL-Escaping sollte das beabsichtigte Konto erhalten statt es zu ändern. Ein Backslash in einer Zeichenkette der Quellsprache, ein Backslash in einem Kontonamen und seine prozentkodierte Darstellung innerhalb einer URI sind getrennte Schichten.
Holen Sie die akzeptierte Identitätsform und das Schema beim Betreiber ein und verwenden Sie dann die passende Anmeldedaten-Schnittstelle. Zufälliges Wechseln zwischen kurzem Namen, Domänennamen und e-mail-artigem Namen liefert schwache Belege für die ursprüngliche 407.