Podstawowe różnice między usługami IIS a programem ASP.NET Development Server (C#)
Autor : Scott Mitchell
Podczas lokalnego testowania aplikacji ASP.NET istnieje prawdopodobieństwo, że 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ć istotne 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 pobierane przez oprogramowanie serwera internetowego, które koordynuje się ze środowiskiem uruchomieniowym ASP.NET w celu wygenerowania i zwrócenia zawartości żądanego zasobu. I nternet I nformation S ervices (IIS) to pakiet usług, które zapewniają typowe funkcje internetowe dla serwerów z systemem Windows. 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 sieci Web 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 programistycznego; jest dostarczany z programem i jest zintegrowany z programem Visual Studio. Jeśli aplikacja internetowa nie została skonfigurowana do używania usług IIS, serwer deweloperów ASP.NET jest automatycznie uruchamiany i używany jako serwer internetowy podczas pierwszego odwiedzania strony internetowej z poziomu programu Visual Studio. Pokazowe aplikacje internetowe utworzone z powrotem w samouczku Określanie plików, które należy wdrożyć , były aplikacjami internetowymi opartymi na systemie plików, które nie zostały skonfigurowane do używania usług IIS. W związku z tym podczas odwiedzania jednej z tych witryn internetowych z poziomu programu Visual Studio jest używany program ASP.NET Development Server.
W idealnym świecie środowiska programistyczne i produkcyjne byłyby identyczne. Jednak jak omówiono w poprzednim samouczku, nie jest niczym niezwykłym, ż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 i 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 w pliku na dysku. Aby ta strona ASP.NET została wykonana bez błędów, 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 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 netto jest to, że mogą istnieć strony internetowe, które są wykonywane bez błędów 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, mam utworzoną stronę w witrynie internetowej Recenzje książek, która tworzy plik na dysku, który przechowuje najnowszą datę i godzinę ktoś oglądał Ucz się ASP.NET 3,5 w 24 godzinach przeglądu. Aby kontynuować, otwórz ~/Tech/TYASP35.aspx stronę i dodaj następujący kod do programu obsługi zdarzeń Page_Load :
protected void Page_Load(object sender, EventArgs e)
{
string filePath = Server.MapPath("~/LastTYASP35Access.txt");
string contents = string.Format("Last accessed on {0} by {1}",
DateTime.Now.ToString(), Request.UserHostAddress);
System.IO.File.WriteAllText(filePath, contents);
}
Uwaga
MetodaFile.WriteAllText tworzy nowy plik, jeśli nie istnieje, a następnie zapisuje do niego określoną zawartość. Jeśli plik już istnieje, istniejąca zawartość zostanie zastąpiona.
Następnie odwiedź stronę przeglądu książki Ucz się ASP.NET 3,5 w ciągu 24 godzin w środowisku deweloperów przy użyciu serwera deweloperskiego ASP.NET. 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, recenzja książki jest taka sama jak poprzednio, 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ę odwiedzonej recenzji 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 zwykły sposób lub komunikat o błędzie przedstawiony na rysunku 2. Niektórzy dostawcy hosta sieci Web przyznają uprawnienia do zapisu anonimowemu kontu komputera ASP.NET. W tym przypadku strona będzie działać bez błędów. Jeśli jednak dostawca hosta sieci Web uniemożliwia dostęp do zapisu dla konta anonimowego, UnauthorizedAccessException jest zgłaszany 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 w pełnym rozmiarze)
Dobrą wiadomością jest to, że większość dostawców hostów internetowych ma jakieś narzędzie do uprawnień, które pozwala określić uprawnienia 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 sieci Web, aby uzyskać pomoc dotyczącą udzielania uprawnień do zapisu do domyślnego konta ASP.NET). Tym razem strona powinna zostać załadowana bez błędu i 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, możliwe, że strony ASP.NET odczytu lub zapisu w systemie plików, odczytu lub zapisu w dzienniku zdarzeń systemu Windows albo odczytu lub zapisu w rejestrze systemu Windows będzie działać zgodnie z oczekiwaniami podczas programowania, ale generują wyjątki w środowisku produkcyjnym. 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
Inną podstawową różnicą między usługami IIS a serwerem deweloperów ASP.NET jest sposób obsługi żądań dotyczących zawartości statycznej. Każde żądanie wchodzące do ASP.NET Development Server, niezależnie od tego, czy dla strony ASP.NET, obrazu lub pliku JavaScript, jest przetwarzane przez środowisko uruchomieniowe ASP.NET. Domyślnie usługi IIS wywołują środowisko uruchomieniowe ASP.NET tylko wtedy, gdy żądanie przychodzi do 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 do 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 uwierzytelnianie adresów 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 swoich 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 ASP.NET witryn internetowych używa uwierzytelniania opartego na formularzach i autoryzacji adresów URL w celu obsługi kont użytkowników oraz 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 platformy 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 moimi samouczkami dotyczącymi zabezpieczeń witryny internetowej.
Rozważ 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 gość spró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 kilka plików PDF i skonfigurujmy witrynę tak, aby korzystała z autoryzacji adresu URL, aby uniemożliwić użytkownikom anonimowym odwiedzanie tego folderu. Jeśli pobierzesz aplikację demonstracyjną, zobaczysz, że utworzono folder o nazwie PrivateDocs i dodano plik PDF z moich samouczków zabezpieczeń witryny internetowej (jak pasujące!). Folder PrivateDocs zawiera Web.config również plik, który określa reguły autoryzacji adresów URL w celu odmowy użytkownikom anonimowym:
<?xml version="1.0"?>
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Na koniec skonfigurowano aplikację internetową do używania uwierzytelniania opartego na formularzach przez zaktualizowanie Web.config pliku w katalogu głównym, zastępując:
<authentication mode="Windows" />
Tym:
<authentication mode="Forms" />
Korzystając z 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 ASP.NET Development Server dla pliku. Serwer ASP.NET Development Server przekazuje żądanie do środowiska uruchomieniowego ASP.NET na potrzeby przetwarzania. Ponieważ jeszcze się nie zalogowaliśmy, a Web.config ponieważ w folderze PrivateDocs skonfigurowano odmawianie 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 o pełnym rozmiarze)
Teraz zobaczmy, jak to działa 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 pobierają i zwracają plik bez wywoływania środowiska uruchomieniowego ASP.NET. W związku z tym 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ą pobrać prywatne pliki PDF, wprowadzając bezpośredni adres URL do pliku (kliknij, aby wyświetlić obraz w pełnym rozmiarze)
Wykonywanie uwierzytelniania Forms-Based i uwierzytelniania adresów URL w plikach statycznych przy użyciu 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ślubi przepływ pracy usług IIS za pomocą przepływu pracy środowiska uruchomieniowego ASP.NET. W skrócie można poinstruować usługi IIS, aby wywołały moduły 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życia 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>
Ten znacznik powoduje, że usługi IIS 7 używają modułów uwierzytelniania i autoryzacji opartego na ASP.NET. Ponownie wdróż aplikację, a następnie ponownie odwiedź plik PDF. Tym razem, gdy usługi IIS obsługują żądanie, daje logikę uwierzytelniania i autoryzacji środowiska uruchomieniowego ASP.NET możliwość sprawdzenia żądania. Ponieważ tylko uwierzytelnieni użytkownicy są autoryzowani do wyświetlania zawartości w PrivateDocs folderze, anonimowy gość jest automatycznie przekierowywany do strony logowania (zapoznaj się z rysunku 3).
Uwaga
Jeśli dostawca hosta sieci Web nadal używa 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 HTTP (na przykład App_Data) i 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 klienta żądającego. 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. Najlepiej, aby to samo oprogramowanie serwera internetowego było używane w obu środowiskach, ponieważ użycie innego oprogramowania dodaje inną zmienną w połączeniu. Jednak łatwość korzystania z serwera deweloperskiego ASP.NET sprawia, że jest to atrakcyjny wybór w środowisku projektowym. Dobrą wiadomością jest to, że istnieje tylko kilka podstawowych różnic między usługami IIS a serwerem ASP.NET Development Server, a jeśli znasz te różnice, możesz wykonać kroki, aby zapewnić, ż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: