Podstawowe różnice między usługami IIS a programem ASP.NET Development Server (VB)
Podczas lokalnego testowania aplikacji ASP.NET prawdopodobnie używasz serwera internetowego ASP.NET Development. Jednak produkcyjna witryna internetowa jest najprawdopodobniej obsługiwana przez usługi IIS. Istnieją pewne różnice między sposobem obsługi żądań przez te serwery internetowe, a te różnice mogą mieć ważne konsekwencje. W tym samouczku przedstawiono niektóre z bardziej niemieckich różnic.
Wprowadzenie
Za każdym razem, gdy użytkownik odwiedza aplikację ASP.NET, przeglądarka wysyła żądanie do witryny internetowej. To żądanie jest odbierane przez oprogramowanie serwera internetowego, które koordynuje się ze środowiskiem uruchomieniowym ASP.NET w celu wygenerowania i zwrócenia zawartości żądanego zasobu. Nternet I nformation S ervices (IIS) to pakiet usług, które zapewniają typowe funkcje internetowe dla serwerów z systemem Windows. Usługi IIS to najczęściej używany serwer internetowy dla aplikacji ASP.NET w środowiskach produkcyjnych; jest to najprawdopodobniej oprogramowanie serwera internetowego używane przez dostawcę hosta sieci Web do obsługi aplikacji ASP.NET. Usługi IIS mogą być również używane jako oprogramowanie serwera internetowego w środowisku programistycznym, chociaż wiąże się to z instalowaniem usług IIS i prawidłowym ich konfigurowaniem.
Serwer ASP.NET Development Server jest alternatywną opcją serwera internetowego dla środowiska deweloperskiego; jest dostarczany z programem i jest zintegrowany z programem Visual Studio. O ile aplikacja internetowa nie została skonfigurowana do korzystania z usług IIS, serwer deweloperów ASP.NET jest automatycznie uruchamiany i używany jako serwer internetowy po raz pierwszy odwiedza stronę internetową z poziomu programu Visual Studio. Demonstracyjne aplikacje internetowe utworzone z powrotem w samouczku Określanie, jakie pliki muszą zostać wdrożone , były aplikacjami internetowymi opartymi na systemie plików, które nie zostały skonfigurowane do korzystania z usług IIS. W związku z tym podczas odwiedzania jednej z tych witryn internetowych z poziomu programu Visual Studio jest używany serwer ASP.NET Development Server.
W idealnym świecie środowiska programistyczne i produkcyjne byłyby identyczne. Jednak jak omówiono w poprzednim samouczku, nie jest rzadkością, że środowiska mają różne ustawienia konfiguracji. Użycie innego oprogramowania serwera internetowego w środowiskach dodaje inną zmienną, którą należy wziąć pod uwagę podczas wdrażania aplikacji. W tym samouczku omówiono kluczowe różnice między usługami IIS a serwerem deweloperów ASP.NET. Ze względu na te różnice istnieją scenariusze, w których kod, który działa bezbłędnie w środowisku deweloperskim, zgłasza wyjątek lub zachowuje się inaczej podczas wykonywania w środowisku produkcyjnym.
Różnice kontekstu zabezpieczeń
Za każdym razem, gdy oprogramowanie serwera internetowego obsługuje żądanie przychodzące, kojarzy to żądanie z określonym kontekstem zabezpieczeń. Te informacje kontekstowe zabezpieczeń są używane przez system operacyjny w celu określenia, jakie akcje są dozwolone przez żądanie. Na przykład strona ASP.NET może zawierać kod, który rejestruje jakiś komunikat na dysku. Aby ta strona ASP.NET mogła zostać wykonana bez błędu, kontekst zabezpieczeń musi mieć odpowiednie uprawnienia na poziomie systemu plików, a mianowicie uprawnienia do zapisu w tym pliku.
Serwer ASP.NET Development Server kojarzy żądania przychodzące z kontekstem zabezpieczeń aktualnie zalogowanego użytkownika. Jeśli użytkownik jest zalogowany na pulpicie jako administrator, strony ASP.NET obsługiwane przez serwer ASP.NET Development Server będą miały takie same uprawnienia dostępu jak administrator. Jednak ASP.NET żądania obsługiwane przez usługi IIS są skojarzone z określonym kontem komputera. Domyślnie konto maszyny usługi sieciowej jest używane przez usługi IIS w wersji 6 i 7, chociaż dostawca hosta sieci Web mógł skonfigurować unikatowe konto dla każdego klienta. Co więcej, dostawca hosta sieci Web prawdopodobnie udzielił ograniczonych uprawnień do tego konta komputera. Wynikiem sieci jest to, że strony internetowe, które są wykonywane bez błędu w środowisku deweloperskim, ale generują wyjątki związane z autoryzacją, gdy są hostowane w środowisku produkcyjnym.
Aby pokazać ten typ błędu w akcji, utworzono stronę w witrynie internetowej Recenzje książek, która tworzy plik na dysku, który przechowuje najnowszą datę i godzinę, w której ktoś wyświetlił recenzję Learn Yourself ASP.NET 3,5 w ciągu 24 godzin . Aby kontynuować, otwórz ~/Tech/TYASP35.aspx stronę i dodaj następujący kod do programu obsługi zdarzeń Page_Load :
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim filePath As String = Server.MapPath("~/LastTYASP35Access.txt")
Dim contents As String = String.Format("Last accessed on {0} by {1}", _
DateTime.Now.ToString(), Request.UserHostAddress)
System.IO.File.WriteAllText(filePath, contents)
End Sub
Uwaga
MetodaFile.WriteAllText tworzy nowy plik, jeśli nie istnieje, a następnie zapisuje do niego określoną zawartość. Jeśli plik już istnieje, to istniejąca zawartość zostanie zastąpiona.
Następnie odwiedź stronę przeglądu książki Teach Yourself ASP.NET 3.5 w ciągu 24 godzin w środowisku projektowym przy użyciu serwera deweloperskiego ASP.NET Development Server. Zakładając, że użytkownik jest zalogowany na komputerze przy użyciu konta, które ma odpowiednie uprawnienia do tworzenia i modyfikowania pliku tekstowego w katalogu głównym aplikacji internetowej, przegląd książki jest wyświetlany tak samo jak wcześniej, ale za każdym razem, gdy strona jest odwiedzana, data i godzina, a adres IP użytkownika jest przechowywany w LastTYASP35Access.txt pliku. Wskaż przeglądarkę temu plikowi; Powinien zostać wyświetlony komunikat podobny do przedstawionego na rysunku 1.
Rysunek 1. Plik tekstowy zawiera ostatnią datę i godzinę odwiedzonego przeglądu książki(Kliknij, aby wyświetlić obraz pełnowymiarowy)
Wdróż aplikację internetową w środowisku produkcyjnym, a następnie odwiedź hostowaną stronę przeglądu książki Teach Yourself ASP.NET 3.5 w ciągu 24 godzin . W tym momencie powinna zostać wyświetlona strona przeglądu książki w normalny sposób lub komunikat o błędzie pokazany na rysunku 2. Niektórzy dostawcy hostów sieci Web udzielają uprawnień zapisu do anonimowego konta komputera ASP.NET, w którym przypadku strona będzie działać bez błędu. Jeśli jednak dostawca hosta sieci Web uniemożliwia dostęp do zapisu dla konta anonimowego, zostanie UnauthorizedAccessException zgłoszony wyjątek , gdy TYASP35.aspx strona próbuje zapisać bieżącą datę i godzinę do LastTYASP35Access.txt pliku.
Rysunek 2. Domyślne konto komputera używane przez usługi IIS nie ma uprawnień do zapisu w systemie plików (kliknij, aby wyświetlić obraz pełnowymiarowy)
Dobrą wiadomością jest to, że większość dostawców hostów internetowych ma pewnego rodzaju narzędzie do uprawnień, które umożliwia określenie uprawnień systemu plików w witrynie internetowej. Udziel anonimowemu kontu ASP.NET dostępu do zapisu w katalogu głównym, a następnie ponownie przejdź do strony przeglądu książki. (W razie potrzeby skontaktuj się z dostawcą hosta internetowego, aby uzyskać pomoc dotyczącą udzielania uprawnień zapisu do domyślnego konta ASP.NET). Tym razem strona powinna zostać załadowana bez błędu, a LastTYASP35Access.txt plik powinien zostać utworzony pomyślnie.
W tym miejscu jest to, że ponieważ ASP.NET Development Server działa w innym kontekście zabezpieczeń niż usługi IIS, istnieje możliwość, że strony ASP.NET odczytujące lub zapisujące w systemie plików, odczytu lub zapisu w dzienniku zdarzeń systemu Windows albo odczytu lub zapisu w rejestrze systemu Windows będą działać zgodnie z oczekiwaniami w zakresie programowania, ale generują wyjątki podczas produkcji. Podczas tworzenia aplikacji internetowej, która zostanie wdrożona w udostępnionym środowisku hostingu sieci Web, nie należy odczytywać ani zapisywać w dzienniku zdarzeń ani w rejestrze systemu Windows. Zanotuj również wszystkie strony ASP.NET odczytujące lub zapisujące w systemie plików, ponieważ może być konieczne przyznanie uprawnień do odczytu i zapisu w odpowiednich folderach w środowisku produkcyjnym.
Różnice w obsłudze zawartości statycznej
Kolejną podstawową różnicą między usługami IIS a serwerem ASP.NET Development Server jest sposób obsługi żądań zawartości statycznej. Każde żądanie, które wchodzi do ASP.NET Development Server, zarówno dla strony ASP.NET, obrazu, jak i pliku JavaScript, jest przetwarzane przez środowisko uruchomieniowe ASP.NET. Domyślnie usługi IIS wywołują środowisko uruchomieniowe ASP.NET tylko wtedy, gdy żądanie jest dostępne dla zasobu ASP.NET, takiego jak strona internetowa ASP.NET, usługa sieci Web itd. Żądania dotyczące zawartości statycznej — obrazy, pliki CSS, pliki JavaScript, pliki PDF, pliki ZIP i podobne — są pobierane przez usługi IIS bez udziału środowiska uruchomieniowego ASP.NET. (Istnieje możliwość poinstruowania usług IIS o pracy ze środowiskiem uruchomieniowym ASP.NET podczas obsługi zawartości statycznej. Aby uzyskać więcej informacji, zapoznaj się z sekcją "Wykonywanie uwierzytelniania Forms-Based i uwierzytelniania adresu URL w plikach statycznych za pomocą usług IIS 7".
Środowisko uruchomieniowe ASP.NET wykonuje szereg kroków w celu wygenerowania żądanej zawartości, w tym uwierzytelniania (identyfikowania osoby żądającej) i autoryzacji (określania, czy żądający ma uprawnienia do wyświetlania żądanej zawartości). Popularną formą uwierzytelniania jest uwierzytelnianie oparte na formularzach, w którym użytkownik jest identyfikowany przez wprowadzenie poświadczeń — zazwyczaj nazwy użytkownika i hasła — do pól tekstowych na stronie internetowej. Po zweryfikowaniu poświadczeń witryna internetowa przechowuje plik cookie biletu uwierzytelniania w przeglądarce użytkownika, który jest wysyłany z każdym kolejnym żądaniem do witryny internetowej i jest używany do uwierzytelniania użytkownika. Ponadto można określić reguły autoryzacji adresów URL , które określają, co użytkownicy mogą lub nie mogą uzyskać dostępu do określonego folderu. Wiele witryn internetowych ASP.NET używa uwierzytelniania opartego na formularzach i autoryzacji adresów URL do obsługi kont użytkowników oraz do definiowania części witryny, które są dostępne tylko dla uwierzytelnionych użytkowników lub użytkowników należących do określonej roli.
Uwaga
Dokładne badanie asp. Uwierzytelnianie oparte na formularzach platformy NET, autoryzacja adresów URL i inne funkcje związane z kontem użytkownika należy zapoznać się z samouczkami dotyczącymi zabezpieczeń witryny internetowej.
Rozważmy witrynę internetową, która obsługuje konta użytkowników przy użyciu autoryzacji opartej na formularzach i ma folder, który przy użyciu autoryzacji adresu URL jest skonfigurowany tak, aby zezwalał tylko na uwierzytelnionych użytkowników. Załóżmy, że ten folder zawiera ASP.NET stron i plików PDF oraz że intencją jest to, że tylko uwierzytelnieni użytkownicy mogą wyświetlać te pliki PDF.
Co się stanie, jeśli odwiedzający próbuje wyświetlić jeden z tych plików PDF, wprowadzając adres URL bezpośrednio na pasku adresu przeglądarki? Aby się dowiedzieć, utwórzmy nowy folder w witrynie Recenzje książek, dodajmy niektóre pliki PDF i skonfigurujemy witrynę do używania autoryzacji adresu URL, aby uniemożliwić anonimowym użytkownikom odwiedzanie tego folderu. Jeśli pobierzesz aplikację demonstracyjną, zobaczysz, że utworzono folder o nazwie PrivateDocs i dodano plik PDF z moich samouczków dotyczących zabezpieczeń witryny internetowej (jak pasujące!). Folder PrivateDocs zawiera Web.config również plik, który określa reguły autoryzacji adresu URL w celu odmowy użytkownikom anonimowym:
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Na koniec skonfigurowano aplikację internetową do korzystania z uwierzytelniania opartego na formularzach przez zaktualizowanie pliku Web.config w katalogu głównym, zastępując:
<authentication mode="Windows" />
Tym:
<authentication mode="Forms" />
Korzystając z serwera ASP.NET Development Server, odwiedź witrynę i wprowadź bezpośredni adres URL do jednego z plików PDF na pasku adresu przeglądarki. Jeśli witryna internetowa skojarzona z tym samouczkiem została pobrana, adres URL powinien wyglądać następująco: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf
Wprowadzenie tego adresu URL na pasku Adres powoduje, że przeglądarka wysyła żądanie do serwera deweloperów ASP.NET dla pliku. Serwer ASP.NET Development Server przekazuje żądanie do środowiska uruchomieniowego ASP.NET na potrzeby przetwarzania. Ponieważ jeszcze się nie zalogowaliśmy i ponieważ Web.config w folderze PrivateDocs skonfigurowano opcję odmowy dostępu anonimowego, środowisko uruchomieniowe ASP.NET automatycznie przekierowuje nas do strony Login.aspx logowania (zobacz Rysunek 3). Podczas przekierowywania użytkownika do strony logowania ASP.NET zawiera ReturnUrl parametr ciągu zapytania wskazujący stronę, którą użytkownik próbował wyświetlić. Po pomyślnym zalogowaniu użytkownika można wrócić do tej strony.
Rysunek 3. Nieautoryzowani użytkownicy są automatycznie przekierowywani do strony logowania (kliknij, aby wyświetlić obraz pełnowymiarowy)
Teraz zobaczmy, jak działa to w środowisku produkcyjnym. Wdróż aplikację i wprowadź bezpośredni adres URL do jednego z plików PDF w folderze PrivateDocs w środowisku produkcyjnym. Spowoduje to wyświetlenie monitu przeglądarki o wysłanie żądania usług IIS dla pliku. Ponieważ zażądano pliku statycznego, usługi IIS pobiera i zwraca plik bez wywoływania środowiska uruchomieniowego ASP.NET. W rezultacie nie przeprowadzono sprawdzania autoryzacji adresu URL; zawartość rzekomo prywatnego pliku PDF jest dostępna dla każdego, kto zna bezpośredni adres URL pliku.
Rysunek 4. Użytkownicy anonimowi mogą pobierać prywatne pliki PDF, wprowadzając bezpośredni adres URL do pliku (kliknij, aby wyświetlić obraz pełnowymiarowy)
Wykonywanie uwierzytelniania Forms-Based i uwierzytelniania adresów URL w plikach statycznych za pomocą usług IIS 7
Istnieje kilka technik, których można użyć do ochrony zawartości statycznej przed nieautoryzowanymi użytkownikami. Usługi IIS 7 wprowadziły zintegrowany potok, który poślubia przepływ pracy usług IIS z przepływem pracy środowiska uruchomieniowego ASP.NET. W skrócie można poinstruować usługi IIS o wywołaniu modułów uwierzytelniania i autoryzacji środowiska uruchomieniowego ASP.NET wszystkich żądań przychodzących (w tym zawartości statycznej, takiej jak pliki PDF). Skontaktuj się z dostawcą hosta sieci Web, aby dowiedzieć się, jak skonfigurować witrynę internetową do korzystania ze zintegrowanego potoku.
Po skonfigurowaniu usług IIS do używania zintegrowanego potoku dodaj następujące znaczniki do Web.config pliku w katalogu głównym:
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Ta adiustacja powoduje, że usługi IIS 7 będą używać modułów uwierzytelniania i autoryzacji opartych na ASP.NET. Ponownie wdróż aplikację, a następnie ponownie odwiedź plik PDF. Tym razem, gdy usługi IIS obsługują żądanie, daje ASP.NET logiki uwierzytelniania i autoryzacji środowiska uruchomieniowego możliwość sprawdzenia żądania. Ponieważ tylko uwierzytelnieni użytkownicy są upoważnieni do wyświetlania zawartości w folderze PrivateDocs , anonimowy gość jest automatycznie przekierowywany do strony logowania (wróć do rysunku 3).
Uwaga
Jeśli dostawca hosta sieci Web nadal korzysta z usług IIS 6, nie można użyć funkcji zintegrowanego potoku. Jednym z obejść jest umieszczenie prywatnych dokumentów w folderze, który uniemożliwia dostęp do protokołu HTTP (na przykład App_Data), a następnie utworzenie strony do obsługi tych dokumentów. Ta strona może być wywoływana GetPDF.aspxi jest przekazywana nazwa pliku PDF za pośrednictwem parametru querystring. Strona GetPDF.aspx najpierw sprawdzi, czy użytkownik ma uprawnienia do wyświetlania pliku, a jeśli tak, użyje Response.WriteFile(filePath) metody , aby wysłać zawartość żądanego pliku PDF z powrotem do żądanego klienta. Ta technika będzie również działać w przypadku usług IIS 7, jeśli nie chcesz włączyć zintegrowanego potoku.
Podsumowanie
Aplikacje internetowe w środowisku produkcyjnym są hostowane przy użyciu oprogramowania serwera internetowego usług IIS firmy Microsoft. Jednak w środowisku programistycznym aplikacja może być hostowana przy użyciu usług IIS lub serwera deweloperskiego ASP.NET. W idealnym przypadku w obu środowiskach należy używać tego samego oprogramowania serwera sieci Web, ponieważ użycie innego oprogramowania dodaje inną zmienną w mieszance. Jednak łatwość użycia serwera deweloperskiego ASP.NET sprawia, że jest to atrakcyjny wybór w środowisku deweloperów. Dobrą wiadomością jest to, że istnieje tylko kilka podstawowych różnic między usługami IIS i ASP.NET Development Server, a jeśli wiesz o tych różnicach, możesz podjąć kroki, aby upewnić się, że aplikacja działa i działa tak samo niezależnie od środowiska.
Szczęśliwe programowanie!
Dalsze informacje
Aby uzyskać więcej informacji na temat tematów omówionych w tym samouczku, zapoznaj się z następującymi zasobami: