2012-06-20 18 views
22

Próbuję uzyskać dostęp do strony internetowej na samej aplikacji asp.net/same domeny, który jest chroniony hasłem. Poświadczenia są takie same zarówno dla strony internetowej wywołującej to połączenie, jak i strony, do której można uzyskać dostęp.WebClient strona użytkowanie z poświadczeniami

Oto kod, a ja nie wiem, dlaczego zawsze skończyć z formularza logowania kod html?

+0

Dlaczego po prostu nie przekierowujesz do tej strony? Pobieranie go za pomocą kodu w procesie serwera oznacza, że ​​* nie używasz * tych samych poświadczeń. Jeśli rozumiem poprawnie, zamiast przeglądarki (z poświadczeniami klienta) dostęp do strony, inny proces na innym komputerze (serwer) pobiera go i przedstawia go klientowi! – shambulator

+0

W jaki sposób są przekazywane te dane uwierzytelniające do strony internetowej? Czy korzysta z uwierzytelniania za pomocą formularzy? –

+0

@shambulator Co masz na myśli przez przekierowanie na tę stronę? Próbuję uzyskać kod html tej strony. – mko

Odpowiedz

48

Podejrzewam, że strona internetowa, do której próbujesz uzyskać dostęp, korzysta z uwierzytelniania za pomocą formularzy. Oznacza to, że będziesz musiał podać poprawny plik cookie uwierzytelniający, jeśli chcesz mieć dostęp do chronionych zasobów. Aby uzyskać ważny plik cookie uwierzytelniający, musisz najpierw uwierzytelnić się, przesyłając żądanie POST na stronę LogOn, która emituje plik cookie. Po pobraniu pliku cookie będziesz mógł go wysłać wraz z kolejnymi żądaniami dotyczącymi chronionych zasobów. Należy również zauważyć, że po wyjęciu z pudełka WebClient nie obsługuje plików cookie. Z tego powodu można napisać niestandardowy cookies świadomego klienta na stronie internetowej:

public class CookieAwareWebClient : WebClient 
{ 
    public CookieAwareWebClient() 
    { 
     CookieContainer = new CookieContainer(); 
    } 
    public CookieContainer CookieContainer { get; private set; } 

    protected override WebRequest GetWebRequest(Uri address) 
    { 
     var request = (HttpWebRequest)base.GetWebRequest(address); 
     request.CookieContainer = CookieContainer; 
     return request; 
    } 
} 

Teraz można korzystać z tego klienta, aby wystrzelić z 2 wnioski:

using (var client = new CookieAwareWebClient()) 
{ 
    var values = new NameValueCollection 
    { 
     { "username", "john" }, 
     { "password", "secret" }, 
    }; 
    client.UploadValues("http://domain.loc/logon.aspx", values); 

    // If the previous call succeeded we now have a valid authentication cookie 
    // so we could download the protected page 
    string result = client.DownloadString("http://domain.loc/testpage.aspx"); 
} 

Oczywiście ze względu na crapiness viewstate z ASP.NET może być konieczne wysłanie kilku innych parametrów podczas żądania logowania. Oto, co możesz zrobić: uwierzytelnij się w przeglądarce i sprawdź w FireBug dokładne parametry i nagłówki, które musisz wysłać.

+0

Rozwiązanie wygląda ładnie i czysto. Czy nazwy kolekcji logowania powinny być rzeczywiście nazwą użytkownika i hasłem? Czy istnieje inny sposób, aby aplikacja używała bieżących poświadczeń, mimo że jest to auth oparte na formularzu? – mko

+0

@John, nie wiem, czy nazwa dla logowania powinna być nazwą użytkownika i hasłem. To całkowicie zależy od tego, w jaki sposób twoja strona logowania jest zaimplementowana i jakich parametrów oczekuje. I nie, nie ma innej drogi. Musisz uzyskać ważny plik cookie uwierzytelniania formularzy, a jedynym sposobem uzyskania takiego pliku cookie jest podanie poprawnych poświadczeń na stronie logowania. To tylko ta strona (mam nadzieję, że :-)) emituje pliki cookie potwierdzające autentyczność formularzy. Kod –

+0

nie działa, ale rozumiem ten pomysł i postaram się go uruchomić. – mko