2009-05-29 16 views
7

La mia app ASP.NET 2.0 crea un HTTPWebRequest in un sito all'interno della rete Intranet aziendale, che utilizza l'autenticazione NTLM. Le credenziali sono passate per un account di servizio, che viene autenticato sul dominio con successo (il registro di protezione lo conferma)HttpWebRequest autenticato con reindirizzamento, credenziali persistenti?

Alcuni codice abbreviato segue ..

HttpWebRequest req = WebRequest.Create(queryUrl) as HttpWebRequest; 
NetworkCredential cred = new NetworkCredential(username, 
       pwd, domain); 
req.Credentials = cred; 

HttpWebResponse response = req.GetResponse() as HttpWebResponse; 

Come parte della richiesta, ci sono un paio di reindirizzamenti (all'interno dello stesso dominio) alla risposta finale - che viene gestito OK sulla mia macchina di sviluppo (Windows 2k)

Quando questa richiesta viene creata dall'ambiente di distribuzione (Windows 2k3), viene visualizzato un errore 401 Non autorizzato restituito dal sito, apparentemente dopo che è stato restituito il primo codice di reindirizzamento (301 Spostati) e la mia richiesta objec t tenta di seguire il reindirizzamento.

Quindi, in pratica, qualcuno è a conoscenza di problemi relativi alle richieste HttpWebadeguate autenticate che seguono i reindirizzamenti?

PS - La soluzione più ovvia è per richiedere semplicemente la pagina reindirizzata a - ma io gli amministratori responsabili del sito intranet vuole monitorare l'utilizzo di mia app da me reindirizzamento attraverso una pagina specifica.

+0

Avete guardato il traffico di rete (ad esempio con Fiddler) per vedere se il client sta facendo ogni tentativo client di autenticazione per l'obiettivo finale del reindirizzamento? L'errore di autenticare automaticamente il server reindirizzato potrebbe essere una misura di sicurezza all'interno di .NET per evitare perdite di credenziali involontarie. – EricLaw

+0

Sto affrontando lo stesso problema e ancora non riesco a capire il problema. http: // stackoverflow.it/questions/3562979/making-a-web-request-to-a-web-page-which-requires-windows-authentication –

risposta

11

Per HttpWebRequest per riutilizzare le credenziali attraverso i reindirizzamenti è necessario utilizzare una cache delle credenziali. Se si assegna semplicemente un oggetto NetworkCredentials, verrà utilizzato solo alla prima richiesta.

Ecco un esempio:

HttpWebRequest req = WebRequest.Create(queryUrl) as HttpWebRequest; 
NetworkCredential cred = new NetworkCredential(username, pwd, domain); 
var cache = new CredentialCache {{queryUrl, "Ntlm", cred}}; 
req.Credentials = cache; 
HttpWebResponse response = req.GetResponse() as HttpWebResponse; 
1

Dipenderà da come la tua autenticazione. schema funziona. Le credenziali di rete aiuteranno solo la parte NTLM di if. Sospetto che il sito a cui stai tentando di accedere utilizzi anche l'autenticazione dei moduli. Se questo è il caso, quando accedi devi ottenere un cookie di autenticazione, dovrai includerlo nelle richieste successive, ad es. dopo un reindirizzamento. Penso che l'oggetto WebRequest abbia una collezione di intestazioni che puoi usare per conservare il cookie. Potrebbe essere una buona idea usare fiddler o firebug per vedere cosa succede quando si naviga normalmente.

-1

Se si utilizza NTLM, questo è il classico problema di 2 hop. Funziona sulla tua macchina di sviluppo perché il client e il server si trovano sulla stessa casella e le credenziali vengono passate almeno una volta (al reindirizzamento della macchina di destinazione finale indovinato)

Quando si distribuisce nell'ambiente di produzione, lì sono 3 macchine coinvolte. Il browser client trasmette le credenziali a server1, quindi server1 tenta di passare le credenziali a server2 che non è consentito. Una soluzione è implementare l'autenticazione Kerberos (un protocollo più stretto) che consentirà al server1 di passare credenziali al server2

+0

Grazie Tion, ma non penso che questo sia il problema in questo caso - l'oggetto credenziali è per un account separato per l'utente che ha effettuato l'accesso alla mia app, quindi c'è solo un hop coinvolto - avrei dovuto dirlo davvero :) È il fatto che c'è un reindirizzamento trasparente coinvolto nell'ottenere la risposta dal server che apparentemente è il problema, se si specifica l'URL finale anziché quello che reindirizza, tutto funziona ... –

Problemi correlati