Nomi utente qualificati dal dominio nelle credenziali proxy
Distingui un nome account opaco dalle API con campi dominio separati ed evita di cambiare l'identità di un account solo per soddisfare la sintassi dell'URL.
Una risposta dice di rimuovere DOMAIN\. Un'altra dice di aggiungerlo. Entrambe le modifiche possono essere sbagliate per il tuo proxy.
Ci sono due domande: quale identità si aspetta il servizio e come l'API scelta rappresenta quell'identità.
| Interfaccia | Cosa stabilire |
|---|---|
| Un unico campo nome account | La sintassi esatta dell'account accettata dall'operatore |
| Un'API credenziali con campo dominio | Se dominio e nome utente debbano essere forniti separatamente |
| Componenti delle credenziali dentro un URI | Come i valori previsti devono essere codificati per quel contenitore |
Per esempio, .NET espone un costruttore NetworkCredential con argomenti separati per nome utente, password e dominio. Mettere un dominio in due campi senza distinzione non è un modo portabile di configurare l'autenticazione integrata.
L'autenticazione Basic è un altro caso: il server interpreta il testo dell'account fornito secondo la propria politica. Trovarsi sulla stessa rete non dimostra che un prefisso di dominio sia implicito. Né un nome qualificato dal dominio è automaticamente un protocollo di autenticazione diverso.
L'escaping dell'URL deve preservare l'account previsto invece di cambiarlo. Una barra rovesciata in una stringa del linguaggio di origine, una barra rovesciata in un nome account e la sua rappresentazione codificata in percentuale dentro un URI sono livelli separati.
Ottieni dall'operatore la forma di identità e lo schema accettati, poi usa l'interfaccia credenziali corrispondente. Alternare a caso tra un nome breve, un nome di dominio e un nome simile a un indirizzo email produce prove deboli sul 407 originale.