Autoryzacja oparta na użytkownikach (C#)

Autor: Scott Mitchell

Uwaga

Od czasu napisania tego artykułu dostawcy członkostwa ASP.NET zostali zastąpioni przez ASP.NET Identity. Zdecydowanie zalecamy aktualizowanie aplikacji w celu korzystania z platformy ASP.NET Identity , a nie dostawców członkostwa proponowanych w czasie pisania tego artykułu. ASP.NET Identity ma wiele zalet w stosunku do systemu członkostwa ASP.NET, w tym :

• Lepsza wydajność
• Ulepszona rozszerzalność i możliwość testowania
• Obsługa uwierzytelniania OAuth, OpenID Connect i uwierzytelniania dwuskładnikowego
• Obsługa tożsamości opartej na oświadczeniach
• Lepsza współdziałanie z platformą ASP.Net Core

Pobierz kod lub pobierz plik PDF

W tym samouczku przyjrzymy się ograniczeniu dostępu do stron i ograniczeniu funkcjonalności na poziomie strony za pomocą różnych technik.

Wprowadzenie

Większość aplikacji internetowych, które oferują konta użytkowników, częściowo w celu ograniczenia niektórych odwiedzających dostępu do określonych stron w witrynie. Na przykład w większości witryn do tablicy wiadomości online wszyscy użytkownicy — anonimowi i uwierzytelnieni — mogą wyświetlać wpisy w tablicy wiadomości, ale tylko uwierzytelnieni użytkownicy mogą odwiedzać stronę internetową, aby utworzyć nowy wpis. Ponadto mogą istnieć strony administracyjne, które są dostępne tylko dla określonego użytkownika (lub określonego zestawu użytkowników). Ponadto funkcjonalność na poziomie strony może się różnić w zależności od użytkownika. Podczas wyświetlania listy wpisów uwierzytelnieni użytkownicy są wyświetlani interfejsu oceny każdego wpisu, natomiast ten interfejs nie jest dostępny dla anonimowych odwiedzających.

ASP.NET ułatwia definiowanie reguł autoryzacji opartych na użytkownikach. Za pomocą tylko odrobiny znaczników w Web.configprogramie można zablokować określone strony internetowe lub całe katalogi, aby były dostępne tylko dla określonego podzestawu użytkowników. Funkcje na poziomie strony można włączać lub wyłączać na podstawie aktualnie zalogowanego użytkownika za pomocą środków programowych i deklaratywnych.

W tym samouczku przyjrzymy się ograniczeniu dostępu do stron i ograniczeniu funkcjonalności na poziomie strony za pomocą różnych technik. Zaczynamy!

Spojrzenie na przepływ pracy autoryzacji adresu URL

Zgodnie z opisem w samouczku Omówienie uwierzytelniania formularzy, gdy środowisko uruchomieniowe ASP.NET przetwarza żądanie ASP.NET zasobu, żądanie zgłasza wiele zdarzeń w trakcie jego cyklu życia. Moduły HTTP to klasy zarządzane, których kod jest wykonywany w odpowiedzi na określone zdarzenie w cyklu życia żądania. ASP.NET dostarczane z wieloma modułami HTTP, które wykonują podstawowe zadania w tle.

Jednym z takich modułów HTTP jest FormsAuthenticationModule. Jak opisano w poprzednich samouczkach, podstawową funkcją elementu FormsAuthenticationModule jest określenie tożsamości bieżącego żądania. Jest to realizowane przez sprawdzenie biletu uwierzytelniania formularzy, który znajduje się w pliku cookie lub osadzonym w adresie URL. Ta identyfikacja odbywa się podczas AuthenticateRequest zdarzenia.

Innym ważnym modułem UrlAuthorizationModuleHTTP jest element , który jest zgłaszany w odpowiedzi naAuthorizeRequest zdarzenie (co ma miejsce po AuthenticateRequest zdarzeniu). Funkcja UrlAuthorizationModule sprawdza znaczniki konfiguracji, Web.config aby określić, czy bieżąca tożsamość ma uprawnienia do odwiedzenia określonej strony. Ten proces jest określany jako autoryzacja adresu URL.

Przeanalizujemy składnię reguł autoryzacji adresów URL w kroku 1, ale najpierw przyjrzyjmy się temu, co robi, UrlAuthorizationModule w zależności od tego, czy żądanie jest autoryzowane, czy nie. UrlAuthorizationModule Jeśli program ustali, że żądanie jest autoryzowane, nie wykonuje żadnych czynności, a żądanie będzie kontynuowane w całym cyklu życia. Jeśli jednak żądanie nie jest autoryzowane, przerywa UrlAuthorizationModule cykl życia i nakazuje Response obiektowi zwrócenie stanu HTTP 401 Brak autoryzacji. W przypadku korzystania z uwierzytelniania formularzy ten stan HTTP 401 nigdy nie jest zwracany do klienta, ponieważ w przypadku FormsAuthenticationModule wykrycia stanu HTTP 401 jest on modyfikowany do przekierowania HTTP 302 do strony logowania.

Rysunek 1 ilustruje przepływ pracy potoku ASP.NET, FormsAuthenticationModule, i UrlAuthorizationModule po nadejściu nieautoryzowanego żądania. W szczególności rysunek 1 przedstawia żądanie anonimowego gościa dla ProtectedPage.aspxelementu , czyli strony, która odmawia dostępu do anonimowych użytkowników. Ponieważ gość jest anonimowy, UrlAuthorizationModule przerywa żądanie i zwraca stan HTTP 401 Brak autoryzacji. Następnie FormsAuthenticationModule konwertuje stan 401 na stronę przekierowania 302 do logowania. Po uwierzytelnieniu użytkownika za pośrednictwem strony logowania nastąpi przekierowanie do ProtectedPage.aspxusługi . Tym razem identyfikator FormsAuthenticationModule identyfikuje użytkownika na podstawie biletu uwierzytelniania. Po uwierzytelnieniu UrlAuthorizationModule osoby odwiedzającej obiekt zezwala na dostęp do strony.

Rysunek 1. Przepływ pracy uwierzytelniania formularzy i autoryzacji adresów URL (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Rysunek 1 przedstawia interakcję, która występuje, gdy anonimowy gość próbuje uzyskać dostęp do zasobu, który nie jest dostępny dla użytkowników anonimowych. W takim przypadku osoba odwiedzająca anonimowa jest przekierowywana do strony logowania ze stroną, którą próbowała odwiedzić określoną w ciągu zapytania. Po pomyślnym zalogowaniu użytkownika nastąpi automatyczne przekierowanie z powrotem do zasobu, który początkowo próbował wyświetlić.

Gdy użytkownik anonimowy wysyła nieautoryzowane żądanie, ten przepływ pracy jest prosty i jest łatwy dla odwiedzających, aby zrozumieć, co się stało i dlaczego. Należy jednak pamiętać, że FormsAuthenticationModule użytkownik przekierowuje dowolnego nieautoryzowanego użytkownika do strony logowania, nawet jeśli żądanie zostanie wykonane przez uwierzytelnionego użytkownika. Może to spowodować mylące środowisko użytkownika, jeśli uwierzytelniony użytkownik próbuje odwiedzić stronę, dla której nie ma uprawnień.

Załóżmy, że nasza witryna internetowa miała skonfigurowane reguły autoryzacji adresów URL, tak aby strona OnlyTito.aspx ASP.NET była dostępna tylko dla Tito. Teraz wyobraź sobie, że Sam odwiedza witrynę, loguje się, a następnie próbuje odwiedzić witrynę OnlyTito.aspx. Spowoduje UrlAuthorizationModule to zatrzymanie cyklu życia żądania i zwrócenie stanu HTTP 401 Brak autoryzacji, który FormsAuthenticationModule wykryje, a następnie przekieruje Sam na stronę logowania. Ponieważ Sam już się zalogował, może się zastanawiać, dlaczego została odesłana do strony logowania. Może ona spowodować, że jej poświadczenia logowania zostały w jakiś sposób utracone lub że wprowadziła nieprawidłowe poświadczenia. Jeśli Sam ponownie wyentuje swoje poświadczenia ze strony logowania, zostanie ona zalogowana (ponownie) i przekierowana do .OnlyTito.aspx Program UrlAuthorizationModule wykryje, że Sam nie może odwiedzić tej strony, a ona zostanie zwrócona na stronę logowania.

Rysunek 2 przedstawia ten mylący przepływ pracy.

Rysunek 2. Domyślny przepływ pracy może prowadzić do mylącego cyklu (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Przepływ pracy przedstawiony na rysunku 2 może szybko obsłużyć nawet najbardziej doświadczonych użytkowników komputerów. Przyjrzymy się sposobom zapobiegania temu mylącemu cyklowi w kroku 2.

Uwaga

ASP.NET używa dwóch mechanizmów, aby określić, czy bieżący użytkownik może uzyskać dostęp do określonej strony internetowej: autoryzacja adresu URL i autoryzacja pliku. Autoryzacja pliku jest implementowana przez program FileAuthorizationModule, który określa urząd, konsultując żądane listy ACL plików. Autoryzacja plików jest najczęściej używana z uwierzytelnianiem systemu Windows, ponieważ listy ACL są uprawnieniami dotyczącymi kont systemu Windows. W przypadku korzystania z uwierzytelniania formularzy wszystkie żądania na poziomie systemu operacyjnego i systemu plików są wykonywane przez to samo konto systemu Windows, niezależnie od użytkownika odwiedzającego witrynę. Ponieważ ta seria samouczków koncentruje się na uwierzytelnianiu formularzy, nie będziemy omawiać autoryzacji plików.

Zakres autoryzacji adresów URL

Jest UrlAuthorizationModule to kod zarządzany, który jest częścią środowiska uruchomieniowego ASP.NET. Przed wersją 7 serwera internetowego usług Informacyjnych (IIS) firmy Microsoft istniała odrębna bariera między potokiem HTTP usług IIS a potokiem ASP.NET środowiska uruchomieniowego. Krótko mówiąc, w usługach IIS 6 i starszych asp. Platforma UrlAuthorizationModule NET jest wykonywana tylko wtedy, gdy żądanie jest delegowane z usług IIS do środowiska uruchomieniowego ASP.NET. Domyślnie usługi IIS przetwarza samą zawartość statyczną — na przykład strony HTML i pliki CSS, JavaScript i pliki obrazów — i wysyłają żądania tylko do środowiska uruchomieniowego ASP.NET, gdy strona z rozszerzeniem .aspx.asmx, lub .ashx jest żądana.

Usługi IIS 7 umożliwiają jednak zintegrowane usługi IIS i potoki ASP.NET. Za pomocą kilku ustawień konfiguracji można skonfigurować usługi IIS 7, aby wywoływać UrlAuthorizationModule dla wszystkich żądań, co oznacza, że reguły autoryzacji adresów URL można zdefiniować dla plików dowolnego typu. Ponadto usługi IIS 7 zawierają własny aparat autoryzacji adresów URL. Aby uzyskać więcej informacji na temat integracji ASP.NET i natywnych funkcji autoryzacji adresów URL usług IIS 7, zobacz Opis autoryzacji adresu URL usług IIS7. Aby uzyskać bardziej szczegółowe informacje na ASP.NET i integracji usług IIS 7, wybierz kopię książki Shahram Khosravi, Professional IIS 7 i ASP.NET Integrated Programming (ISBN: 978-0470152539).

W skrócie w wersjach wcześniejszych niż IIS 7 reguły autoryzacji adresów URL są stosowane tylko do zasobów obsługiwanych przez środowisko uruchomieniowe ASP.NET. Jednak w przypadku usług IIS 7 można użyć natywnej funkcji autoryzacji adresów URL usług IIS lub zintegrować platformę ASP. Platforma NET jest UrlAuthorizationModule w potoku HTTP usług IIS, rozszerzając w ten sposób tę funkcję na wszystkie żądania.

Uwaga

Istnieją pewne subtelne, ale ważne różnice w sposobie asp. UrlAuthorizationModule Funkcja autoryzacji adresów URL platformy NET i usług IIS 7 przetwarza reguły autoryzacji. Ten samouczek nie analizuje funkcji autoryzacji adresów URL usług IIS 7 ani różnic w sposobie analizowania reguł autoryzacji w porównaniu z elementem UrlAuthorizationModule. Aby uzyskać więcej informacji na temat tych tematów, zapoznaj się z dokumentacją usług IIS 7 w witrynie MSDN lub w www.iis.net.

Krok 1. Definiowanie reguł autoryzacji adresów URL w programieWeb.config

Określa UrlAuthorizationModule , czy udzielić lub odmówić dostępu do żądanego zasobu dla określonej tożsamości na podstawie reguł autoryzacji adresu URL zdefiniowanych w konfiguracji aplikacji. Reguły autoryzacji są pisane w elemecie <authorization> w postaci elementów podrzędnych <allow> i <deny> . Każdy element podrzędny <allow> i <deny> może określać:

• Określony użytkownik
• Rozdzielana przecinkami lista użytkowników
• Wszyscy użytkownicy anonimowi, oznaczeni znakiem zapytania (?)
• Wszyscy użytkownicy oznaczeni gwiazdką (*)

Poniższy znacznik ilustruje, jak używać reguł autoryzacji adresu URL, aby zezwolić użytkownikom Tito i Scott i odmówić wszystkim innym:

<authorization>
 <allow users="Tito, Scott" />
 <deny users="*" />
</authorization>

Element <allow> definiuje, co użytkownicy są dozwolone — Tito i Scott — podczas gdy <deny> element instruuje, że wszyscy użytkownicy są odrzucani.

Uwaga

<allow> Elementy i <deny> mogą również określać reguły autoryzacji dla ról. W przyszłym samouczku przeanalizujemy autoryzację opartą na rolach.

Następujące ustawienie zapewnia dostęp do wszystkich osób innych niż Sam (w tym osób odwiedzających anonimowych):

<authorization>
 <deny users="Sam" />
</authorization>

Aby zezwolić tylko na uwierzytelnionych użytkowników, użyj następującej konfiguracji, która odmawia dostępu wszystkim użytkownikom anonimowym:

<authorization>
 <deny users="?" />
</authorization>

Reguły autoryzacji są definiowane w elemecie <system.web> w Web.config pliku i mają zastosowanie do wszystkich zasobów ASP.NET w aplikacji internetowej. Często aplikacja ma różne reguły autoryzacji dla różnych sekcji. Na przykład w witrynie handlu elektronicznego wszyscy odwiedzający mogą przeglądać produkty, przeglądać recenzje produktów, przeszukiwać katalog itd. Jednak tylko uwierzytelnieni użytkownicy mogą uzyskać dostęp do wyewidencjonowania lub stron w celu zarządzania historią wysyłki. Ponadto mogą istnieć części witryny, które są dostępne tylko przez wybranych użytkowników, takich jak administratorzy witryny.

ASP.NET ułatwia zdefiniowanie różnych reguł autoryzacji dla różnych plików i folderów w witrynie. Reguły autoryzacji określone w pliku folderu Web.config głównego mają zastosowanie do wszystkich zasobów ASP.NET w lokacji. Jednak te domyślne ustawienia autoryzacji można zastąpić dla określonego folderu, dodając element Web.config z sekcją <authorization> .

Zaktualizujmy naszą witrynę internetową, aby tylko uwierzytelnieni użytkownicy mogli odwiedzać strony ASP.NET w folderze Membership . Aby to osiągnąć, musimy dodać Web.config plik do Membership folderu i ustawić jego ustawienia autoryzacji, aby uniemożliwić anonimowym użytkownikom. Kliknij prawym przyciskiem myszy Membership folder w Eksplorator rozwiązań, wybierz menu Dodaj nowy element z menu kontekstowego i dodaj nowy plik konfiguracji sieci Web o nazwie Web.config.

Rysunek 3. Dodawanie Web.config pliku do Membership folderu (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

W tym momencie projekt powinien zawierać dwa Web.config pliki: jeden w katalogu głównym i jeden w folderze Membership .

Rysunek 4. Aplikacja powinna teraz zawierać dwa Web.config pliki (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Zaktualizuj plik konfiguracji w folderze Membership , aby uniemożliwić dostęp do użytkowników anonimowych.

<?xml version="1.0"?>
<configuration>
 <system.web>
 <authorization>
 <deny users="?" />
 </authorization>
 </system.web>
</configuration>

To wszystko!

Aby przetestować tę zmianę, odwiedź stronę główną w przeglądarce i upewnij się, że jesteś wylogowany. Ponieważ domyślne zachowanie aplikacji ASP.NET polega na zezwalaniu wszystkim odwiedzającym, a ponieważ nie wprowadziliśmy żadnych modyfikacji autoryzacji do pliku katalogu Web.config głównego, możemy odwiedzić pliki w katalogu głównym jako anonimowy gość.

Kliknij link Tworzenie kont użytkowników znajdujący się w lewej kolumnie. Spowoduje to przejście do .~/Membership/CreatingUserAccounts.aspx Web.config Ponieważ plik w folderze Membership definiuje reguły autoryzacji, aby uniemożliwić dostęp anonimowy, UrlAuthorizationModule przerywa żądanie i zwraca stan HTTP 401 Brak autoryzacji. Spowoduje FormsAuthenticationModule to zmodyfikowanie stanu przekierowania 302, wysyłając nas na stronę logowania. Zwróć uwagę, że strona, do którego próbujemy uzyskać dostęp (CreatingUserAccounts.aspx), jest przekazywana do strony logowania za pośrednictwem parametru ReturnUrl querystring.

Rysunek 5. Ponieważ reguły autoryzacji adresów URL uniemożliwiają dostęp anonimowy, nastąpi przekierowanie do strony logowania (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Po pomyślnym zalogowaniu CreatingUserAccounts.aspx nastąpi przekierowanie do strony. Tym razem UrlAuthorizationModule zezwala na dostęp do strony, ponieważ nie jesteśmy już anonimowi.

Stosowanie reguł autoryzacji adresów URL do określonej lokalizacji

Ustawienia autoryzacji zdefiniowane w <system.web> sekcji Web.config mają zastosowanie do wszystkich zasobów ASP.NET w tym katalogu i jego podkatalogach (dopóki nie zostanie to zastąpione przez inny Web.config plik). W niektórych przypadkach możemy jednak chcieć, aby wszystkie zasoby ASP.NET w danym katalogu miały określoną konfigurację autoryzacji z wyjątkiem jednej lub dwóch określonych stron. Można to osiągnąć, dodając <location> element w Web.configpliku , wskazując go do pliku, którego reguły autoryzacji różnią się i definiując tam unikatowe reguły autoryzacji.

Aby zilustrować <location> użycie elementu do zastąpienia ustawień konfiguracji dla określonego zasobu, dostosujmy ustawienia autoryzacji, aby tylko Tito mógł odwiedzić stronę CreatingUserAccounts.aspx. Aby to osiągnąć, dodaj <location> element do Membership pliku folderu Web.config i zaktualizuj jego znaczniki, tak aby wyglądał on następująco:

<?xml version="1.0"?>
<configuration>
 <system.web>
 <authorization>
 <deny users="?" />
 </authorization>
 </system.web>

 <location path="CreatingUserAccounts.aspx">
 <system.web>
 <authorization>
 <allow users="Tito" />
 <deny users="*" />
 </authorization>
 </system.web>
 </location>
</configuration>

Element <authorization> w <system.web> pliku definiuje domyślne reguły autoryzacji adresów URL dla zasobów ASP.NET w folderze Membership i jego podfolderach. Element <location> umożliwia zastąpienie tych reguł dla określonego zasobu. W powyższym znaczniku <location> element odwołuje się do CreatingUserAccounts.aspx strony i określa jej reguły autoryzacji, takie jak zezwalanie Tito, ale odmawianie wszystkim innym.

Aby przetestować tę zmianę autoryzacji, zacznij od odwiedzenia witryny internetowej jako użytkownik anonimowy. Jeśli spróbujesz odwiedzić dowolną stronę w Membership folderze, na przykład UserBasedAuthorization.aspx, UrlAuthorizationModule żądanie zostanie odrzucone i nastąpi przekierowanie do strony logowania. Po zalogowaniu się jako, powiedzmy, Scott, można odwiedzić dowolną stronę w folderze z Membership wyjątkiem CreatingUserAccounts.aspx. Próba zalogowania CreatingUserAccounts.aspx się jako każda osoba, ale Tito spowoduje nieautoryzowaną próbę dostępu, przekierowanie z powrotem na stronę logowania.

Uwaga

Element <location> musi pojawić się poza elementem konfiguracji <system.web> . Należy użyć oddzielnego <location> elementu dla każdego zasobu, którego ustawienia autoryzacji chcesz zastąpić.

Zobacz, jak używaUrlAuthorizationModulereguł autoryzacji do udzielania lub odmowy dostępu

Określa UrlAuthorizationModule , czy autoryzować określoną tożsamość dla określonego adresu URL, analizując reguły autoryzacji adresów URL pojedynczo, zaczynając od pierwszego i pracując w dół. Po znalezieniu dopasowania użytkownik otrzymuje lub odmawia dostępu, w zależności od tego, czy dopasowanie zostało znalezione w elemecie <allow> lub <deny> . Jeśli nie zostanie znalezione dopasowanie, użytkownik otrzyma dostęp. W związku z tym, jeśli chcesz ograniczyć dostęp, konieczne jest użycie <deny> elementu jako ostatniego elementu w konfiguracji autoryzacji adresu URL. Jeśli pominięto<deny>element, wszyscy użytkownicy otrzymają dostęp.

Aby lepiej zrozumieć proces używany przez UrlAuthorizationModule program do określania urzędu, rozważ przykładowe reguły autoryzacji adresów URL, które omówiliśmy wcześniej w tym kroku. Pierwsza reguła <allow> to element, który umożliwia dostęp do Tito i Scotta. Druga reguła <deny> to element, który odmawia dostępu wszystkim. Jeśli anonimowy UrlAuthorizationModule użytkownik odwiedza, rozpoczyna się od pytania, czy jest anonimowy Scott, czy Tito? Oczywiście odpowiedź brzmi Nie, więc przechodzi do drugiej reguły. Czy anonimowy jest w zestawie wszystkich? Ponieważ tutaj odpowiedź brzmi Tak, reguła <deny> jest wprowadzana, a odwiedzający jest przekierowywany do strony logowania. Podobnie, jeśli Jisun odwiedza, UrlAuthorizationModule zaczyna się pytając, Czy Jisun albo Scott, czy Tito? Ponieważ ona nie jest, UrlAuthorizationModule przechodzi do drugiego pytania, Czy Jisun w zestawie wszystkich? Ona jest, więc ona też jest odrzucony dostęp. Wreszcie, jeśli Tito odwiedza, pierwsze pytanie zadane przez to UrlAuthorizationModule jest twierdząca odpowiedź, więc Tito otrzymuje dostęp.

UrlAuthorizationModule Ponieważ reguły autoryzacji są przetwarzane od góry w dół, zatrzymując się w dowolnym dopasowaniu, ważne jest, aby bardziej szczegółowe reguły miały bardziej szczegółowe reguły. Oznacza to, że aby zdefiniować reguły autoryzacji, które zabraniają stosowania programu Jisun i anonimowych użytkowników, ale zezwalają wszystkim innym uwierzytelnionymi użytkownikom, należy zacząć od najbardziej konkretnej reguły — tej, która ma wpływ na jisun — a następnie przejść do mniej specyficznych reguł — zezwalających wszystkim innym uwierzytelnionymi użytkownikom, ale odmawiając wszystkim użytkownikom anonimowym. Następujące reguły autoryzacji adresów URL implementują te zasady, najpierw odmawiając programu Jisun, a następnie odmawiając dowolnego użytkownika anonimowego. Każdy uwierzytelniony użytkownik inny niż Jisun otrzyma dostęp, ponieważ żadna z tych <deny> instrukcji nie będzie zgodna.

<authorization>
 <deny users="Jisun" />
 <deny users="?" />
</authorization>

Krok 2. Naprawianie przepływu pracy dla nieautoryzowanych, uwierzytelnionych użytkowników

Jak wspomniano wcześniej w tym samouczku w sekcji A Look at the URL Authorization Workflow (Przegląd przepływu pracy autoryzacji adresu URL), w dowolnym momencie, gdy wystąpi nieautoryzowane żądanie, UrlAuthorizationModule przerywa żądanie i zwraca stan HTTP 401 Brak autoryzacji. Ten stan 401 jest modyfikowany przez FormsAuthenticationModule element w stanie przekierowania 302, który wysyła użytkownika na stronę logowania. Ten przepływ pracy występuje w dowolnym nieautoryzowanym żądaniu, nawet jeśli użytkownik jest uwierzytelniony.

Zwracanie uwierzytelnionego użytkownika do strony logowania może je mylić, ponieważ użytkownik zalogował się już do systemu. Trochę pracy możemy ulepszyć ten przepływ pracy, przekierowując uwierzytelnionych użytkowników, którzy wysyłają nieautoryzowane żądania do strony, która wyjaśnia, że próbował uzyskać dostęp do strony z ograniczeniami.

Zacznij od utworzenia nowej strony ASP.NET w folderze głównym aplikacji internetowej o nazwie UnauthorizedAccess.aspx; nie zapomnij skojarzyć tej strony ze stroną wzorcową Site.master . Po utworzeniu tej strony usuń kontrolkę Zawartość, która odwołuje się do LoginContent elementu ContentPlaceHolder, aby wyświetlić domyślną zawartość strony wzorcowej. Następnie dodaj komunikat, który wyjaśnia sytuację, a mianowicie, że użytkownik próbował uzyskać dostęp do chronionego zasobu. Po dodaniu takiego komunikatu UnauthorizedAccess.aspx znacznik deklaratywny strony powinien wyglądać podobnie do następującego:

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true"
CodeFile="UnauthorizedAccess.aspx.cs" Inherits="UnauthorizedAccess"
Title="Untitled Page" %>

<asp:Content ID="Content1" ContentPlaceHolderID="MainContent"
Runat="Server">
 <h2>Unauthorized Access</h2>
 <p>
 You have attempted to access a page that you are not authorized to view.
 </p>
 <p>
 If you have any questions, please contact the site administrator.
 </p>
</asp:Content>

Teraz musimy zmienić przepływ pracy, aby w przypadku nieautoryzowanego żądania był wykonywany przez uwierzytelnionego użytkownika, który jest wysyłany do UnauthorizedAccess.aspx strony zamiast strony logowania. Logika, która przekierowuje nieautoryzowane żądania do strony logowania, jest pochowana w prywatnej metodzie FormsAuthenticationModule klasy, więc nie możemy dostosować tego zachowania. Możemy jednak dodać własną logikę do strony logowania, która w razie potrzeby przekierowuje użytkownika do UnauthorizedAccess.aspxadresu .

FormsAuthenticationModule Gdy przekierowanie nieautoryzowanego gościa do strony logowania dołącza żądany, nieautoryzowany adres URL do ciągu zapytania o nazwie ReturnUrl. Jeśli na przykład nieautoryzowany użytkownik próbował odwiedzić usługę OnlyTito.aspx, FormsAuthenticationModule przekierowanie ich do Login.aspx?ReturnUrl=OnlyTito.aspxelementu . W związku z tym, jeśli strona logowania zostanie osiągnięta przez uwierzytelnionego użytkownika z ciągiem zapytania zawierającym ReturnUrl parametr, wiemy, że ten nieuwierzytelniony użytkownik próbował odwiedzić stronę, która nie jest autoryzowana do wyświetlania. W takim przypadku chcemy przekierować ją do UnauthorizedAccess.aspx.

Aby to osiągnąć, dodaj następujący kod do programu obsługi zdarzeń strony Page_Load logowania:

protected void Page_Load(object sender, EventArgs e)
{
    if (!Page.IsPostBack)
    {
        if (Request.IsAuthenticated && !string.IsNullOrEmpty(Request.QueryString["ReturnUrl"]))
        // This is an unauthorized, authenticated request...
        Response.Redirect("~/UnauthorizedAccess.aspx");
    }
}

Powyższy kod przekierowuje uwierzytelnionych, nieautoryzowanych użytkowników do UnauthorizedAccess.aspx strony. Aby zobaczyć tę logikę w działaniu, odwiedź witrynę jako anonimowy gość i kliknij link Tworzenie kont użytkowników w lewej kolumnie. Spowoduje to przejście do ~/Membership/CreatingUserAccounts.aspx strony, która w kroku 1 została skonfigurowana tak, aby zezwalała na dostęp tylko do Tito. Ponieważ użytkownicy anonimowi są zabronieni, FormsAuthenticationModule przekierowuje nas z powrotem do strony logowania.

W tym momencie jesteśmy anonimowi, więc Request.IsAuthenticated zwracamy i false nie jesteśmy przekierowywani do UnauthorizedAccess.aspx. Zamiast tego zostanie wyświetlona strona logowania. Zaloguj się jako użytkownik inny niż Tito, taki jak Bruce. Po wprowadzeniu odpowiednich poświadczeń strona logowania przekierowuje nas z powrotem do ~/Membership/CreatingUserAccounts.aspx. Jednak ponieważ ta strona jest dostępna tylko dla Tito, nie jesteśmy autoryzowani do jej wyświetlania i są natychmiast zwracani na stronę logowania. Tym razem jednak Request.IsAuthenticated zwraca true wartość (a ReturnUrl parametr ciągu zapytania istnieje), więc nastąpi przekierowanie do UnauthorizedAccess.aspx strony.

Rysunek 6. Uwierzytelnieni, nieautoryzowani użytkownicy są przekierowywani do UnauthorizedAccess.aspx (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Ten dostosowany przepływ pracy przedstawia bardziej rozsądne i proste środowisko użytkownika przez zwarcie cyklu przedstawionego na rysunku 2.

Krok 3. Ograniczanie funkcjonalności na podstawie aktualnie zalogowanego użytkownika

Autoryzacja adresu URL ułatwia określanie reguł autoryzacji grubszych. Jak pokazano w kroku 1, z autoryzacją adresu URL możemy zwięźle określić, jakie tożsamości są dozwolone i które z nich są odrzucane podczas przeglądania określonej strony lub wszystkich stron w folderze. W niektórych scenariuszach możemy jednak zezwolić wszystkim użytkownikom na odwiedzanie strony, ale ograniczyć funkcjonalność strony na podstawie odwiedzania jej przez użytkownika.

Rozważmy przypadek witryny internetowej handlu elektronicznego, która umożliwia uwierzytelnieni odwiedzającym przeglądanie swoich produktów. Gdy anonimowy użytkownik odwiedza stronę produktu, zobaczy tylko informacje o produkcie i nie będzie miał możliwości opuszczenia przeglądu. Jednak uwierzytelniony użytkownik odwiedzający tę samą stronę będzie widzieć interfejs przeglądania. Jeśli uwierzytelniony użytkownik nie przejrzył jeszcze tego produktu, interfejs umożliwi im przesłanie przeglądu; w przeciwnym razie pokaże im wcześniej przesłany przegląd. Aby wykonać ten scenariusz, strona produktu może zawierać dodatkowe informacje i oferować rozszerzone funkcje dla tych użytkowników, którzy pracują w firmie handlu elektronicznego. Na przykład strona produktu może wyświetlić listę zapasów w magazynie i uwzględnić opcje edytowania ceny i opisu produktu po odwiedzeniu przez pracownika.

Takie reguły autoryzacji szczegółowości można zaimplementować deklaratywnie lub programowo (lub za pomocą jakiejś kombinacji tych dwóch). W następnej sekcji zobaczymy, jak zaimplementować autoryzację szczegółową za pomocą kontrolki LoginView. Następnie zapoznamy się z technikami programowymi. Zanim jednak będziemy mogli przyjrzeć się zastosowaniu reguł autoryzacji szczegółowej, najpierw musimy utworzyć stronę, której funkcjonalność zależy od użytkownika odwiedzającego go.

Utwórzmy stronę zawierającą listę plików w określonym katalogu w obiekcie GridView. Oprócz wyświetlania listy nazw, rozmiaru i innych informacji, kontrolka GridView będzie zawierać dwie kolumny LinkButtons: jedną zatytułowaną View (Widok) i jedną zatytułowaną Delete (Usuń). Jeśli klikniesz przycisk View LinkButton, zostanie wyświetlona zawartość wybranego pliku; Jeśli klikniesz przycisk Usuń linkButton, plik zostanie usunięty. Na początku utwórzmy tę stronę, tak aby jej funkcja wyświetlania i usuwania została udostępniona wszystkim użytkownikom. W sekcjach Korzystanie z kontrolki LoginView i Programowe ograniczanie funkcjonalności zobaczymy, jak włączyć lub wyłączyć te funkcje na podstawie użytkownika odwiedzającego stronę.

Uwaga

Strona ASP.NET, która zostanie skompilowana, używa kontrolki GridView do wyświetlania listy plików. Ponieważ w tej serii samouczków skupiono się na uwierzytelnianiu formularzy, autoryzacji, kontach użytkowników i rolach, nie chcę poświęcać zbyt dużo czasu na omawianie wewnętrznej pracy kontrolki GridView. Chociaż ten samouczek zawiera szczegółowe instrukcje krok po kroku dotyczące konfigurowania tej strony, nie zagłębia się w szczegółowe informacje o tym, dlaczego dokonano pewnych wyborów lub jakie mają wpływ na renderowane dane wyjściowe. Aby zapoznać się z dokładnym badaniem kontrolki GridView, zapoznaj się z serią samouczków Praca z danymi w ASP.NET 2.0.

Zacznij od otwarcia UserBasedAuthorization.aspx pliku w folderze Membership i dodania kontrolki GridView do strony o nazwie FilesGrid. W tagu inteligentnym kontrolki GridView kliknij link Edytuj kolumny, aby uruchomić okno dialogowe Pola. W tym miejscu usuń zaznaczenie pola wyboru Automatyczne generowanie pól w lewym dolnym rogu. Następnie dodaj przycisk Wybierz, przycisk Usuń i dwa pola powiązane w lewym górnym rogu (przyciski Wybierz i Usuń można znaleźć w obszarze Typ CommandField). Ustaw właściwość Wybierz przycisk SelectText na Wyświetl, a pierwsze właściwości BoundField HeaderText DataField na Name. Ustaw właściwość second BoundField HeaderText na Size w bajtach, jej właściwość Length, jej DataField DataFormatString właściwość na {0:N0} Wartość i jej HtmlEncode właściwość na False.

Po skonfigurowaniu kolumn kontrolki GridView kliknij przycisk OK, aby zamknąć okno dialogowe Pola. Z okno Właściwości ustaw właściwość GridView DataKeyNames na FullName. W tym momencie znacznik deklaratywnej kontrolki GridView powinien wyglądać następująco:

<asp:GridView ID="FilesGrid" DataKeyNames="FullName" runat="server" AutoGenerateColumns="False">
 <Columns>
 <asp:CommandField SelectText="View" ShowSelectButton="True"/>
 <asp:CommandField ShowDeleteButton="True" />
 <asp:BoundField DataField="Name" HeaderText="Name" />
 <asp:BoundField DataField="Length" DataFormatString="{0:N0}"
 HeaderText="Size in Bytes" HtmlEncode="False" />
 </Columns>
</asp:GridView>

Po utworzeniu znaczników GridView możemy napisać kod, który pobierze pliki w określonym katalogu i powiąże je z kontrolką GridView. Dodaj następujący kod do programu obsługi zdarzeń strony Page_Load :

protected void Page_Load(object sender, EventArgs e)
{
    if (!Page.IsPostBack)
    {
        string appPath = Request.PhysicalApplicationPath;
        DirectoryInfo dirInfo = new DirectoryInfo(appPath);

        FileInfo[] files = dirInfo.GetFiles();

        FilesGrid.DataSource = files;
        FilesGrid.DataBind();
    }
}

Powyższy kod używa DirectoryInfo klasy do uzyskania listy plików w folderze głównym aplikacji. Metoda GetFiles() zwraca wszystkie pliki w katalogu jako tablicę FileInfo obiektów, która jest następnie powiązana z obiektem GridView. Obiekt FileInfo ma asortyment właściwości, takich jak Name, Lengthi IsReadOnly, między innymi. Jak widać na podstawie jego znaczników deklaratywnego, kontrolka GridView wyświetla tylko Name właściwości i Length .

Uwaga

Klasy DirectoryInfo i FileInfo znajdują się w System.IO przestrzeni nazw. W związku z tym należy poprzeć te nazwy klas nazwami przestrzeni nazw lub zaimportować przestrzeń nazw do pliku klasy (za pośrednictwem metody using System.IO).

Pośmiń chwilę, aby odwiedzić tę stronę za pośrednictwem przeglądarki. Zostanie wyświetlona lista plików znajdujących się w katalogu głównym aplikacji. Kliknięcie dowolnego elementu View lub Delete LinkButtons spowoduje powrót, ale nie zostanie wykonana żadna akcja, ponieważ nie utworzymy jeszcze niezbędnych procedur obsługi zdarzeń.

Rysunek 7. Widok GridView wyświetla listę plików w katalogu głównym aplikacji internetowej (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Potrzebujemy środków do wyświetlenia zawartości wybranego pliku. Wróć do programu Visual Studio i dodaj kontrolkę TextBox o nazwie FileContents powyżej kontrolki GridView. Ustaw jej TextMode właściwość na MultiLine i Rows jej Columns właściwości na odpowiednio 95% i 10.

<asp:TextBox ID="FileContents" runat="server" Rows="10"
TextMode="MultiLine" Width="95%"></asp:TextBox>

Następnie utwórz procedurę obsługi zdarzeń dla zdarzenia GridView SelectedIndexChanged i dodaj następujący kod:

protected void FilesGrid_SelectedIndexChanged(object sender, EventArgs e)
{
    // Open the file and display it
    string fullFileName = FilesGrid.SelectedValue.ToString();
    string contents = File.ReadAllText(fullFileName);
    FileContents.Text = contents;
}

Ten kod używa właściwości GridView SelectedValue do określenia pełnej nazwy pliku wybranego pliku. DataKeys Wewnętrznie kolekcja jest przywołyowana w celu uzyskania SelectedValueelementu , dlatego konieczne jest ustawienie właściwości GridView DataKeyNames na Name, zgodnie z opisem we wcześniejszej sekcji tego kroku. Klasa File służy do odczytywania zawartości wybranego pliku do ciągu, który jest następnie przypisywany do FileContents właściwości TextBoxText, wyświetlając w ten sposób zawartość wybranego pliku na stronie.

Rysunek 8. Zawartość wybranego pliku jest wyświetlana w polu tekstowym (kliknij, aby wyświetlić obraz pełnowymiarowy)

Uwaga

Jeśli wyświetlisz zawartość pliku zawierającego znaczniki HTML, a następnie spróbujesz wyświetlić lub usunąć plik, zostanie wyświetlony HttpRequestValidationException błąd. Dzieje się tak, ponieważ po przesłaniu zwrotnym zawartość elementu TextBox jest wysyłana z powrotem do serwera internetowego. Domyślnie ASP.NET zgłasza HttpRequestValidationException błąd przy każdym wykryciu potencjalnie niebezpiecznej zawartości zwrotnej, takiej jak znacznik HTML. Aby wyłączyć ten błąd, wyłącz walidację żądania dla strony, dodając ValidateRequest="false" do @Page dyrektywy. Aby uzyskać więcej informacji na temat korzyści z weryfikacji żądań, a także środków ostrożności, które należy podjąć podczas jego wyłączania, przeczytaj Artykuł Weryfikacja żądań — zapobieganie atakom skryptowym.

Na koniec dodaj procedurę obsługi zdarzeń z następującym kodem dla zdarzenia GridView:RowDeleting

protected void FilesGrid_RowDeleting(object sender, GridViewDeleteEventArgs e)
{
    string fullFileName = FilesGrid.DataKeys[e.RowIndex].Value.ToString();
    FileContents.Text = string.Format("You have opted to delete {0}.", fullFileName);

    // To actually delete the file, uncomment the following line
    // File.Delete(fullFileName);
}

Kod po prostu wyświetla pełną nazwę pliku do usunięcia w polu tekstowym FileContents bez faktycznego usunięcia pliku.

Rysunek 9. Kliknięcie przycisku Usuń nie powoduje usunięcia pliku (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

W kroku 1 skonfigurowaliśmy reguły autoryzacji adresów URL, aby uniemożliwić użytkownikom anonimowym wyświetlanie stron w folderze Membership . Aby lepiej pokazać szczegółowe uwierzytelnianie, zezwólmy anonimowym użytkownikom na odwiedzanie UserBasedAuthorization.aspx strony, ale z ograniczoną funkcjonalnością. Aby otworzyć tę stronę do uzyskania dostępu przez wszystkich użytkowników, dodaj następujący <location> element do Web.config pliku w folderze Membership :

<location path="UserBasedAuthorization.aspx">
 <system.web>
 <authorization>
 <allow users="*" />
 </authorization>
 </system.web>
</location>

Po dodaniu tego <location> elementu przetestuj nowe reguły autoryzacji adresów URL, wyloguj się z witryny. Jako użytkownik anonimowy należy zezwolić na odwiedzanie UserBasedAuthorization.aspx strony.

Obecnie każdy uwierzytelniony lub anonimowy użytkownik może odwiedzić UserBasedAuthorization.aspx stronę i wyświetlić lub usunąć pliki. Zróbmy to tak, aby tylko uwierzytelnieni użytkownicy mogli wyświetlać zawartość pliku, a tylko Tito może usunąć plik. Takie reguły autoryzacji szczegółowości można stosować deklaratywnie, programowo lub za pomocą kombinacji obu metod. Użyjmy podejścia deklaratywnego, aby ograniczyć, kto może wyświetlać zawartość pliku; Użyjemy podejścia programowego, aby ograniczyć, kto może usunąć plik.

Korzystanie z kontrolki LoginView

Jak widzieliśmy w poprzednich samouczkach, kontrolka LoginView jest przydatna do wyświetlania różnych interfejsów dla uwierzytelnionych i anonimowych użytkowników i oferuje łatwy sposób ukrywania funkcji, które nie są dostępne dla użytkowników anonimowych. Ponieważ użytkownicy anonimowi nie mogą wyświetlać ani usuwać plików, musimy pokazać FileContents pole tekstowe tylko wtedy, gdy strona jest odwiedzana przez uwierzytelnionego użytkownika. Aby to osiągnąć, dodaj kontrolkę LoginView do strony, nadaj jej LoginViewForFileContentsTextBoxnazwę i przenieś FileContents znacznik deklaratywny TextBox do kontrolki LoggedInTemplateLoginView .

<asp:LoginView ID=" LoginViewForFileContentsTextBox " runat="server">
 <LoggedInTemplate>
 <p>
 <asp:TextBox ID="FileContents" runat="server" Rows="10"
 TextMode="MultiLine" Width="95%"></asp:TextBox>
 </p>
 </LoggedInTemplate>
</asp:LoginView>

Kontrolki sieci Web w szablonach elementu LoginView nie są już bezpośrednio dostępne z poziomu klasy za pomocą kodu. Na przykład FilesGrid programy obsługi zdarzeń i RowDeleting gridView SelectedIndexChanged odwołują się obecnie do kontrolki FileContents TextBox z kodem, na przykład:

FileContents.Text = text;

Jednak ten kod nie jest już prawidłowy. Przeniesienie pola FileContents TextBox do pola tekstowego LoggedInTemplate nie może być bezpośrednio dostępne. Zamiast tego musimy użyć FindControl("controlId") metody , aby programowo odwoływać się do kontrolki. Zaktualizuj programy obsługi zdarzeń, FilesGrid aby odwołyłyły się do kontrolki TextBox w następujący sposób:

TextBox FileContentsTextBox = LoginViewForFileContentsTextBox.FindControl("FileContents") as TextBox;
FileContentsTextBox.Text = text;

Po przeniesieniu kontrolki TextBox do obiektu LoginView LoggedInTemplate i zaktualizowaniu kodu strony w celu odwołania się do kontrolki TextBox przy użyciu FindControl("controlId") wzorca odwiedź stronę jako użytkownik anonimowy. Jak pokazano na rysunku 10, pole FileContents tekstowe nie jest wyświetlane. Jednak nadal jest wyświetlany widok LinkButton.

Rysunek 10. Kontrolka LoginView renderuje tylko kontrolkę FileContents TextBox dla uwierzytelnionych użytkowników (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Jednym ze sposobów ukrycia przycisku Wyświetl dla użytkowników anonimowych jest przekonwertowanie pola GridView na pole TemplateField. Spowoduje to wygenerowanie szablonu zawierającego deklaratywne znaczniki dla elementu LinkButton widoku. Następnie możemy dodać kontrolkę LoginView do pola TemplateField i umieścić element LinkButton w kontrolce LoggedInTemplateLoginView, ukrywając w ten sposób przycisk Wyświetl przed anonimowych odwiedzających. Aby to osiągnąć, kliknij link Edytuj kolumny z tagu inteligentnego GridView, aby uruchomić okno dialogowe Pola. Następnie wybierz przycisk Wybierz z listy w lewym dolnym rogu, a następnie kliknij link Konwertuj to pole na pole szablonu. Spowoduje to zmodyfikowanie znacznika deklaratywnego pola z:

<asp:CommandField SelectText="View" ShowSelectButton="True"/>

Do:

<asp:TemplateField ShowHeader="False">
 <ItemTemplate>
 <asp:LinkButton ID="LinkButton1" runat="server" CausesValidation="False"
 CommandName="Select" Text="View"></asp:LinkButton>
 </ItemTemplate>
</asp:TemplateField>

Na tym etapie możemy dodać element LoginView do pola TemplateField. Poniższy znacznik powoduje wyświetlenie elementu LinkButton widoku tylko dla uwierzytelnionych użytkowników.

<asp:TemplateField ShowHeader="False">
 <ItemTemplate>
 <asp:LoginView ID="LoginView1" runat="server">
 <LoggedInTemplate>
 <asp:LinkButton ID="LinkButton1" runat="server" CausesValidation="False"
 CommandName="Select" Text="View"></asp:LinkButton>
 </LoggedInTemplate>
 </asp:LoginView>
 </ItemTemplate>
</asp:TemplateField>

Jak pokazano na rysunku 11, wynik końcowy nie jest taki ładny, jak kolumna Widok jest nadal wyświetlana, mimo że kolumna View LinkButtons w kolumnie jest ukryta. Przyjrzymy się, jak ukryć całą kolumnę GridView (a nie tylko LinkButton) w następnej sekcji.

Rysunek 11. Kontrolka LoginView ukrywa kontrolkę LinkButtons widoku dla osób odwiedzających anonimowych (kliknij, aby wyświetlić obraz pełnowymiarowy)

Programowe ograniczanie funkcjonalności

W niektórych okolicznościach techniki deklaratywne nie są wystarczające do ograniczenia funkcjonalności strony. Na przykład dostępność niektórych funkcji strony może zależeć od kryteriów poza tym, czy użytkownik odwiedzający stronę jest anonimowy, czy uwierzytelniony. W takich przypadkach różne elementy interfejsu użytkownika mogą być wyświetlane lub ukryte za pomocą środków programowych.

Aby ograniczyć funkcjonalność programowo, musimy wykonać dwa zadania:

1. Ustal, czy użytkownik odwiedzający stronę może uzyskać dostęp do funkcji i
2. Programowe modyfikowanie interfejsu użytkownika na podstawie tego, czy użytkownik ma dostęp do danej funkcji.

Aby zademonstrować zastosowanie tych dwóch zadań, zezwólmy tylko Tito na usuwanie plików z kontrolki GridView. Naszym pierwszym zadaniem jest ustalenie, czy to Tito odwiedza stronę. Po ustaleniu tej wartości musimy ukryć (lub pokazać) kolumnę Delete kontrolki GridView. Kolumny kontrolki GridView są dostępne za pośrednictwem jej Columns właściwości. Kolumna jest renderowana tylko wtedy, gdy jej Visible właściwość jest ustawiona na true (wartość domyślna).

Dodaj następujący kod do Page_Load procedury obsługi zdarzeń przed powiązaniem danych z kontrolką GridView:

// Is this Tito visiting the page?
string userName = User.Identity.Name;
if (string.Compare(userName, "Tito", true) == 0)
    // This is Tito, SHOW the Delete column
    FilesGrid.Columns[1].Visible = true;
else
    // This is NOT Tito, HIDE the Delete column
    FilesGrid.Columns[1].Visible = false;

Jak omówiono w samouczku Omówienie uwierzytelniania formularzy, User.Identity.Name zwraca nazwę tożsamości. Odpowiada to nazwie użytkownika wprowadzonej w kontrolce Logowanie. Jeśli odwiedza stronę Tito, właściwość drugiej kolumny Visible kontrolki GridView jest ustawiona na truewartość ; w przeciwnym razie jest ustawiona wartość false. Wynikiem netto jest to, że gdy ktoś inny niż Tito odwiedza stronę, inny uwierzytelniony użytkownik lub anonimowy użytkownik, kolumna Usuń nie jest renderowana (zobacz Rysunek 12); Jednak gdy Tito odwiedza stronę, kolumna Usuń jest obecna (patrz Rysunek 13).

Rysunek 12. Kolumna usuwania nie jest renderowana po odwiedzeniu przez osobę inną niż Tito (na przykład Bruce) (kliknij, aby wyświetlić obraz pełnowymiarowy)

Rysunek 13. Renderowanie kolumny usuwania dla Tito (kliknij, aby wyświetlić obraz pełnowymiarowy)

Krok 4. Stosowanie reguł autoryzacji do klas i metod

W kroku 3 uniemożliwiliśmy użytkownikom anonimowym wyświetlanie zawartości pliku i zabroniliśmy wszystkim użytkownikom, ale Tito usuwania plików. Zostało to osiągnięte przez ukrycie skojarzonych elementów interfejsu użytkownika dla nieautoryzowanych odwiedzających za pomocą technik deklaratywnych i programistycznych. W naszym prostym przykładzie prawidłowe ukrywanie elementów interfejsu użytkownika było proste, ale co z bardziej złożonymi witrynami, w których może istnieć wiele różnych sposobów wykonywania tych samych funkcji? Co się stanie w przypadku ograniczenia tej funkcjonalności dla nieautoryzowanych użytkowników, co się stanie, jeśli zapomnimy ukryć lub wyłączyć wszystkie odpowiednie elementy interfejsu użytkownika?

Łatwym sposobem zapewnienia, że nie można uzyskać dostępu do określonego elementu funkcjonalności przez nieautoryzowanego użytkownika, jest dekorowanie tej klasy lub metody za pomocą atrybutu PrincipalPermission. Gdy środowisko uruchomieniowe platformy .NET używa klasy lub wykonuje jedną z jego metod, sprawdza, czy bieżący kontekst zabezpieczeń ma uprawnienia do używania klasy lub wykonywania metody. Atrybut PrincipalPermission udostępnia mechanizm, za pomocą którego można zdefiniować te reguły.

Pokażmy użycie atrybutu PrincipalPermission w programach obsługi zdarzeń i RowDeleting GridViewSelectedIndexChanged, aby uniemożliwić wykonywanie przez anonimowych użytkowników i użytkowników innych niż Tito. Wszystko, co musimy zrobić, to dodać odpowiedni atrybut na szczycie każdej definicji funkcji:

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]
protected void FilesGrid_SelectedIndexChanged(object sender, EventArgs e)
{
    ...
}

[PrincipalPermission(SecurityAction.Demand, Name="Tito")]
protected void FilesGrid_RowDeleting(object sender, GridViewDeleteEventArgs e)
{
    ...
}

Atrybut programu SelectedIndexChanged obsługi zdarzeń określa, że tylko uwierzytelnieni użytkownicy mogą wykonać program obsługi zdarzeń, gdzie jako atrybut RowDeleting programu obsługi zdarzeń ogranicza wykonywanie do Tito.

Jeśli w jakiś sposób użytkownik inny niż Tito próbuje wykonać procedurę obsługi zdarzeń lub nieuwierzytelnionego użytkownika próbuje wykonać RowDeleting SelectedIndexChanged program obsługi zdarzeń, środowisko uruchomieniowe platformy .NET zgłosi błąd SecurityException.

Rysunek 14. Jeśli kontekst zabezpieczeń nie ma autoryzacji do wykonania metody, jest SecurityException zgłaszany (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Uwaga

Aby zezwolić wielu kontekstom zabezpieczeń na dostęp do klasy lub metody, udekoruj klasę lub metodę za pomocą atrybutu PrincipalPermission dla każdego kontekstu zabezpieczeń. Oznacza to, że aby umożliwić zarówno Tito, jak i Bruce wykonanie RowDeleting procedury obsługi zdarzeń, dodaj dwa PrincipalPermission atrybuty:

[PrincipalPermission(SecurityAction.Demand, Name="Tito")]

[PrincipalPermission(SecurityAction.Demand, Name="Bruce")]

Oprócz ASP.NET stron wiele aplikacji ma również architekturę obejmującą różne warstwy, takie jak logika biznesowa i warstwy dostępu do danych. Te warstwy są zwykle implementowane jako biblioteki klas i oferują klasy i metody do wykonywania funkcji związanych z logiką biznesową i danymi. Atrybut PrincipalPermission jest przydatny do stosowania reguł autoryzacji do tych warstw.

Aby uzyskać więcej informacji na temat używania atrybutu do definiowania reguł autoryzacji dla klas i metod, zapoznaj się z wpisem PrincipalPermission scotta Guthrie w blogu Dodawanie reguł autoryzacji do warstw biznesowych i danych przy użyciu poleceniaPrincipalPermissionAttributes .

Podsumowanie

W tym samouczku przedstawiono sposób stosowania reguł autoryzacji opartych na użytkownikach. Zaczęliśmy od przyjrzenia się platformie ASP. Struktura autoryzacji adresów URL platformy NET. Na każdym żądaniu aparat UrlAuthorizationModule ASP.NET sprawdza reguły autoryzacji adresów URL zdefiniowane w konfiguracji aplikacji, aby określić, czy tożsamość jest autoryzowana do uzyskiwania dostępu do żądanego zasobu. Krótko mówiąc, autoryzacja adresu URL ułatwia określenie reguł autoryzacji dla określonej strony lub dla wszystkich stron w określonym katalogu.

Struktura autoryzacji adresów URL stosuje reguły autoryzacji na podstawie strony po stronie. W przypadku autoryzacji adresu URL żądający tożsamość jest autoryzowana do uzyskiwania dostępu do określonego zasobu lub nie. Jednak wiele scenariuszy wywołuje bardziej szczegółowe reguły autoryzacji. Zamiast definiować, kto może uzyskiwać dostęp do strony, może być konieczne zezwolenie wszystkim na dostęp do strony, ale wyświetlanie różnych danych lub oferowanie różnych funkcji w zależności od użytkownika odwiedzającego stronę. Autoryzacja na poziomie strony zwykle polega na ukrywaniu określonych elementów interfejsu użytkownika w celu zapobiegania nieautoryzowanym użytkownikom uzyskiwania dostępu do zabronionych funkcji. Ponadto można użyć atrybutów, aby ograniczyć dostęp do klas i wykonywania jej metod dla niektórych użytkowników.

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:

• Dodawanie reguł autoryzacji do warstw biznesowych i danych przy użyciu polecenia PrincipalPermissionAttributes
• autoryzacja ASP.NET
• Zmiany między zabezpieczeniami usług IIS6 i IIS7
• Konfigurowanie określonych plików i podkatalogów
• Ograniczanie funkcjonalności modyfikacji danych na podstawie użytkownika
• Kontrolka LoginView — przewodniki Szybki start
• Opis autoryzacji adresu URL usług IIS7
• UrlAuthorizationModule Dokumentacja techniczna
• Praca z danymi w ASP.NET 2.0

Informacje o autorze

Scott Mitchell, autor wielu książek ASP/ASP.NET i założyciel 4GuysFromRolla.com, współpracuje z technologiami internetowymi firmy Microsoft od 1998 roku. Scott pracuje jako niezależny konsultant, trener i pisarz. Jego najnowsza książka to Sams Teach Yourself ASP.NET 2.0 w 24 godzinach. Scott można uzyskać na mitchell@4guysfromrolla.com stronie lub za pośrednictwem swojego bloga pod adresem http://ScottOnWriting.NET.

Specjalne podziękowania

Ta seria samouczków została omówiona przez wielu przydatnych recenzentów. Chcesz przejrzeć nadchodzące artykuły MSDN? Jeśli tak, upuść mi wiersz pod adresem mitchell@4GuysFromRolla.com.

PoprzedniNastępny