Sdílet prostřednictvím

Ověřování založené na uživatelích (C#)

  • Článek

Scott Mitchell

Poznámka

Od napsání tohoto článku se zprostředkovatelé členství ASP.NET nahradili službou ASP.NET Identity. Důrazně doporučujeme aktualizovat aplikace tak, aby používaly platformu ASP.NET Identity Platform místo zprostředkovatelů členství, které se objevovalo v době psaní tohoto článku. ASP.NET Identity má oproti systému členství ASP.NET řadu výhod, mezi které patří:

  • Lepší výkon
  • Vylepšená rozšiřitelnost a testovatelnost
  • Podpora OAuth, OpenID Connect a dvojúrovňového ověřování
  • Podpora identit založených na deklarací identity
  • Lepší interoperabilita s ASP.Net Core

Stažení kódu nebo stažení souboru PDF

V tomto kurzu se podíváme na omezení přístupu ke stránkám a omezení funkčnosti na úrovni stránky pomocí různých technik.

Úvod

Většina webových aplikací, které nabízejí uživatelské účty, tak částečně omezuje určité návštěvníky v přístupu k určitým stránkám na webu. Například na většině online webů s tabulí zpráv můžou příspěvky na této tabuli zobrazit všichni uživatelé – anonymní a ověření – ale webovou stránku a vytvořit nový příspěvek můžou jenom ověření uživatelé. A můžou existovat stránky pro správu, které jsou přístupné jenom konkrétnímu uživateli (nebo určité skupině uživatelů). Funkce na úrovni stránky se navíc můžou lišit u jednotlivých uživatelů. Při prohlížení seznamu příspěvků se ověřeným uživatelům zobrazí rozhraní pro hodnocení jednotlivých příspěvků, zatímco toto rozhraní není k dispozici anonymním návštěvníkům.

ASP.NET usnadňuje definování autorizačních pravidel založených na uživatelích. Jen s trochou kódu v Web.configje možné určité webové stránky nebo celé adresáře uzamknout tak, aby byly přístupné jenom určené podmnožině uživatelů. Funkce na úrovni stránek je možné zapnout nebo vypnout na základě aktuálně přihlášeného uživatele programovým a deklarativním způsobem.

V tomto kurzu se podíváme na omezení přístupu ke stránkám a omezení funkčnosti na úrovni stránky pomocí různých technik. Pusťme se do toho.

Podívejte se na pracovní postup autorizace adres URL

Jak je popsáno v kurzu Přehled ověřování pomocí formulářů , když modul runtime ASP.NET zpracuje požadavek na ASP.NET prostředek, vyvolá požadavek během svého životního cyklu řadu událostí. Moduly HTTP jsou spravované třídy, jejichž kód se spouští v reakci na konkrétní událost v životním cyklu požadavku. ASP.NET se dodává s několika moduly HTTP, které provádějí základní úlohy na pozadí.

Jedním z takových modulů HTTP je FormsAuthenticationModule. Jak bylo popsáno v předchozích kurzech, primární funkcí objektu FormsAuthenticationModule je určení identity aktuálního požadavku. Toho se dosáhne kontrolou lístku ověřování formulářů, který se nachází v souboru cookie nebo je vložený v adrese URL. Tato identifikace probíhá během AuthenticateRequest události.

Dalším důležitým modulem UrlAuthorizationModuleHTTP je , který je vyvolána v reakci na AuthorizeRequest událost (která nastane po AuthenticateRequest události). Nástroj UrlAuthorizationModule zkontroluje kód konfigurace v Web.config souboru a určí, jestli má aktuální identita oprávnění k návštěvě zadané stránky. Tento proces se označuje jako autorizace adres URL.

V kroku 1 prozkoumáme syntaxi pravidel autorizace adres URL, ale nejprve se podíváme na to, co UrlAuthorizationModule dělá v závislosti na tom, jestli je žádost autorizována, nebo ne. UrlAuthorizationModule Pokud objekt určí, že je žádost autorizována, neprovede nic a požadavek bude pokračovat v průběhu svého životního cyklu. Pokud však požadavek není autorizovaný, přeruší UrlAuthorizationModule životní cyklus a dá objektu pokyn Response , aby vrátil stav HTTP 401 Neautorizováno . Při použití ověřování pomocí formulářů se tento stav HTTP 401 nikdy nevrátí klientovi, protože pokud FormsAuthenticationModule zjistí, že se stav HTTP 401 upraví na HTTP 302 Přesměrování na přihlašovací stránku.

Obrázek 1 znázorňuje pracovní postup kanálu ASP.NET, objektu FormsAuthenticationModuleUrlAuthorizationModule a při přijetí neoprávněného požadavku. Konkrétně obrázek 1 ukazuje požadavek anonymního návštěvníka na ProtectedPage.aspx, což je stránka, která anonymním uživatelům odepře přístup. Vzhledem k tomu, že je návštěvník anonymní, UrlAuthorizationModule přeruší požadavek a vrátí stav HTTP 401 Neautorizováno. Pak FormsAuthenticationModule převede stav 401 na stránku Přesměrování na přihlášení 302. Po ověření uživatele prostřednictvím přihlašovací stránky je přesměrován na ProtectedPage.aspxadresu . Tentokrát FormsAuthenticationModule identifikuje uživatele na základě jeho ověřovacího lístku. Teď, když je návštěvník ověřený, UrlAuthorizationModule povolí přístup ke stránce.

Pracovní postup ověřování pomocí formulářů a autorizace adres URL

Obrázek 1: Pracovní postup ověřování pomocí formulářů a autorizace adres URL (kliknutím zobrazíte obrázek v plné velikosti)

Obrázek 1 znázorňuje interakci, ke které dochází, když se anonymní návštěvník pokusí o přístup k prostředku, který není k dispozici anonymním uživatelům. V takovém případě je anonymní návštěvník přesměrován na přihlašovací stránku se stránkou, o které se pokusila navštívit, uvedenou v řetězci dotazu. Jakmile se uživatel úspěšně přihlásí, bude automaticky přesměrován zpět na prostředek, který se původně pokoušel zobrazit.

Pokud je neoprávněný požadavek proveden anonymním uživatelem, je tento pracovní postup jednoduchý a návštěvník snadno pochopí, co se stalo a proč. Mějte ale na FormsAuthenticationModule paměti, že přesměruje všechny neautorizované uživatele na přihlašovací stránku, a to i v případě, že žádost odešle ověřený uživatel. To může vést k matoucímu uživatelskému prostředí, pokud se ověřený uživatel pokusí navštívit stránku, pro kterou nemá oprávnění.

Představte si, že náš web má autorizační pravidla adresy URL nakonfigurovaná tak, aby byla ASP.NET stránka OnlyTito.aspx přístupná pouze pro Tito. Teď si představte, že Sam navštíví web, přihlásí se a pak se pokusí navštívit OnlyTito.aspx. Nástroj UrlAuthorizationModule zastaví životní cyklus požadavku a vrátí stav HTTP 401 Neautorizováno, který FormsAuthenticationModule zjistí a přesměruje Sama na přihlašovací stránku. Vzhledem k tomu, že se Sam už přihlásil, může se divit, proč byla odeslána zpět na přihlašovací stránku. Může mít důvod, že se její přihlašovací údaje nějak ztratily nebo zadala neplatné přihlašovací údaje. Pokud Sam znovu zadá svoje přihlašovací údaje z přihlašovací stránky, bude (znovu) přihlášena a přesměrována na OnlyTito.aspx. Nástroj UrlAuthorizationModule zjistí, že Sam nemůže navštívit tuto stránku a vrátí se na přihlašovací stránku.

Obrázek 2 znázorňuje tento matoucí pracovní postup.

Výchozí pracovní postup může vést k matoucímu cyklu.

Obrázek 2: Výchozí pracovní postup může vést k matoucímu cyklu (kliknutím zobrazíte obrázek v plné velikosti)

Pracovní postup znázorněný na obrázku 2 může rychle zastinit i ty nejpočítačově zdatnější návštěvníky. Způsoby, jak tomuto matoucímu cyklu zabránit, se podíváme v kroku 2.

Poznámka

ASP.NET používá k určení, jestli má aktuální uživatel přístup ke konkrétní webové stránce, dva mechanismy: autorizace adres URL a autorizace souborů. Autorizaci souborů implementuje FileAuthorizationModulenástroj , který určuje autoritu na základě konzultace se seznamy ACL požadovaných souborů. Autorizace souborů se nejčastěji používá s ověřováním systému Windows, protože seznamy ACL jsou oprávnění, která platí pro účty Systému Windows. Při ověřování pomocí formulářů jsou všechny požadavky na úrovni operačního systému a systému souborů spouštěny stejným účtem Systému Windows bez ohledu na to, který uživatel web navštíví. Vzhledem k tomu, že se tato série kurzů zaměřuje na ověřování pomocí formulářů, nebudeme se zabývat autorizací souborů.

Rozsah autorizace adresy URL

Je UrlAuthorizationModule spravovaný kód, který je součástí modulu runtime ASP.NET. Před verzí 7 webového serveru Internetové informační služby (IIS) společnosti Microsoft byla mezi kanálem HTTP služby IIS a kanálem modulu ASP.NET runtime odlišná bariéra. Stručně řečeno, ve službě IIS 6 a starších verzích asp. NET se UrlAuthorizationModule spustí pouze v případě, že je požadavek delegovaný ze služby IIS na modul runtime ASP.NET. Ve výchozím nastavení služba IIS zpracovává statický obsah samotný – jako jsou stránky HTML a šablony stylů CSS, JavaScript a soubory obrázků – a požadavky na modul runtime ASP.NET předává pouze v případě, že je požadována stránka s příponou .aspx, .asmxnebo .ashx .

SLUŽBA IIS 7 však umožňuje integrované kanály služby IIS a ASP.NET. Pomocí několika nastavení konfigurace můžete nastavit službu IIS 7 tak, aby vyvolávala UrlAuthorizationModule příkaz pro všechny požadavky, což znamená, že pravidla autorizace adres URL je možné definovat pro soubory libovolného typu. Služba IIS 7 navíc obsahuje vlastní modul pro autorizaci adres URL. Další informace o integraci ASP.NET a nativních funkcích autorizace URL služby IIS 7 najdete v tématu Principy autorizace adres URL služby IIS7. Podrobnější pohled na integraci ASP.NET a IIS 7 najdete v kopii knihy Shahram Khosravi Professional IIS 7 and ASP.NET Integrated Programming (ISBN: 978-0470152539).

Stručně řečeno, ve verzích předcházejících službě IIS 7 se autorizační pravidla adres URL použijí jenom na prostředky, které zpracovává modul runtime ASP.NET. Se službou IIS 7 je však možné použít nativní funkci autorizace adres URL služby IIS nebo integrovat ASP. UrlAuthorizationModule NET se do kanálu HTTP služby IIS, čímž se tato funkce rozšiřuje na všechny požadavky.

Poznámka

V asp je několik drobných, ale důležitých rozdílů. UrlAuthorizationModule Funkce autorizace adres URL a služby IIS 7 zpracovávají autorizační pravidla. Tento kurz nezkoumá funkce autorizace adres URL služby IIS 7 ani rozdíly ve způsobu parsování autorizačních pravidel v porovnání s UrlAuthorizationModule. Další informace o těchto tématech najdete v dokumentaci ke službě IIS 7 na webu MSDN nebo na www.iis.net.

Krok 1: Definování pravidel autorizace adres URL vWeb.config

Určuje UrlAuthorizationModule , jestli se má udělit nebo odepřít přístup k požadovanému prostředku pro konkrétní identitu na základě autorizačních pravidel adres URL definovaných v konfiguraci aplikace. Autorizační pravidla jsou napsaná v elementu<authorization> ve formě podřízených elementů <allow> a <deny> . Každý <allow> a <deny> podřízený prvek může určovat:

  • Konkrétní uživatel
  • Seznam uživatelů oddělených čárkami
  • Všichni anonymní uživatelé označeni otazníkem (?)
  • Všichni uživatelé, označeni hvězdičkou (*)

Následující kód ukazuje, jak pomocí autorizačních pravidel adresy URL povolit uživatelům Tito a Scott a odepřít všechny ostatní:

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

Element <allow> definuje, kteří uživatelé jsou povoleni - Tito a Scott - zatímco <deny> element instruuje, že všichni uživatelé jsou odepřeni.

Poznámka

Elementy <allow> a <deny> mohou také určovat autorizační pravidla pro role. Autorizaci na základě rolí prozkoumáme v budoucím kurzu.

Následující nastavení udělí přístup komukoli jinému než Samu (včetně anonymních návštěvníků):

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

Pokud chcete povolit jenom ověřené uživatele, použijte následující konfiguraci, která odepře přístup všem anonymním uživatelům:

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

Autorizační pravidla jsou definována v elementu <system.web> v Web.config a platí pro všechny ASP.NET prostředky ve webové aplikaci. Aplikace má často různá autorizační pravidla pro různé oddíly. Například na webu elektronického obchodování můžou všichni návštěvníci prohlížet produkty, prohlížet si recenze produktů, vyhledávat v katalogu atd. K pokladně nebo stránkám, které spravují historii expedice, se ale můžou dostat jenom ověření uživatelé. Kromě toho můžou existovat části webu, ke kterým mají přístup jenom vybraní uživatelé, například správci webu.

ASP.NET usnadňuje definování různých autorizačních pravidel pro různé soubory a složky na webu. Autorizační pravidla zadaná v souboru kořenové složky Web.config se vztahují na všechny ASP.NET prostředky na webu. Tato výchozí nastavení autorizace se ale dají pro určitou složku přepsat přidáním Web.config s oddílem <authorization> .

Pojďme náš web aktualizovat tak, aby stránky ASP.NET ve Membership složce mohli navštěvovat jenom ověření uživatelé. Abychom toho dosáhli, musíme do Membership složky přidat Web.config soubor a nastavit jeho autorizaci tak, aby odepřely anonymní uživatele. Klikněte pravým tlačítkem myši na Membership složku v Průzkumník řešení, v místní nabídce zvolte nabídku Přidat novou položku a přidejte nový soubor webové konfigurace s názvem Web.config.

Přidání souboru Web.config do složky Členství

Obrázek 3: Přidání Web.config souboru do Membership složky (kliknutím zobrazíte obrázek v plné velikosti)

V tomto okamžiku by projekt měl obsahovat dva Web.config soubory: jeden v kořenovém adresáři a jeden ve Membership složce.

Vaše aplikace by teď měla obsahovat dva soubory Web.config.

Obrázek 4: Vaše aplikace by teď měla obsahovat dva Web.config soubory (kliknutím zobrazíte obrázek v plné velikosti)

Aktualizujte konfigurační soubor ve Membership složce tak, aby zakazovala přístup anonymním uživatelům.

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

A je to!

Pokud chcete tuto změnu otestovat, přejděte v prohlížeči na domovskou stránku a ujistěte se, že jste odhlášeni. Vzhledem k tomu, že ASP.NET aplikace ve výchozím nastavení povoluje všechny návštěvníky, a protože jsme neprodáli žádné úpravy autorizace souboru kořenového Web.config adresáře, můžeme soubory v kořenovém adresáři navštívit jako anonymní návštěvník.

V levém sloupci klikněte na odkaz Vytváření uživatelských účtů. Tím přejdete na ~/Membership/CreatingUserAccounts.aspx. Vzhledem k tomu, že Web.config soubor ve Membership složce definuje autorizační pravidla zakazující anonymní přístup, UrlAuthorizationModule požadavek přeruší a vrátí stav HTTP 401 Neautorizováno. Změní FormsAuthenticationModule ho na stav přesměrování 302 a odešle nás na přihlašovací stránku. Všimněte si, že stránka, ke které jsme se pokoušeli získat přístup (CreatingUserAccounts.aspx), se předává přihlašovací stránce prostřednictvím parametru ReturnUrl querystring.

Vzhledem k tomu, že pravidla autorizace adres URL zakazují anonymní přístup, jsme přesměrováni na přihlašovací stránku.

Obrázek 5: Vzhledem k tomu, že pravidla autorizace adres URL zakazují anonymní přístup, jsme přesměrováni na přihlašovací stránku (kliknutím zobrazíte obrázek v plné velikosti).

Po úspěšném přihlášení jsme přesměrováni na CreatingUserAccounts.aspx stránku. Tentokrát UrlAuthorizationModule povolí přístup na stránku, protože už nejsme anonymní.

Použití autorizačních pravidel adres URL na konkrétní umístění

Nastavení autorizace definované v oddílu <system.web>Web.config pro platí pro všechny ASP.NET prostředky v tomto adresáři a jeho podadresářích (dokud se jinak nepřepíše jiným Web.config souborem). V některých případech ale můžeme chtít, aby všechny ASP.NET prostředky v daném adresáři měly určitou konfiguraci autorizace s výjimkou jedné nebo dvou konkrétních stránek. Toho lze dosáhnout přidáním <location> prvku v Web.configsouboru , který ho odkáže na soubor, jehož autorizační pravidla se liší, a definováním jeho jedinečných autorizačních pravidel v tomto souboru.

Abychom si ukázali použití elementu <location> k přepsání nastavení konfigurace pro konkrétní prostředek, přizpůsobíme nastavení autorizace tak, aby pouze Tito mohl navštívit CreatingUserAccounts.aspx. Toho dosáhnete tak, že do Membership souboru složky přidáte <location>Web.config element a aktualizujete jeho kód tak, aby vypadal takto:

<?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> v <system.web> definuje výchozí pravidla autorizace adresy URL pro ASP.NET prostředky ve Membership složce a jejích podsložkách. Element <location> nám umožňuje přepsat tato pravidla pro konkrétní prostředek. Ve výše uvedeném kódu <location> element odkazuje na CreatingUserAccounts.aspx stránku a určuje její autorizační pravidla, jako například povolit Tito, ale odepřít všechny ostatní.

Pokud chcete tuto změnu autorizace otestovat, začněte tím, že navštívíte web jako anonymní uživatel. Pokud se pokusíte navštívit libovolnou Membership stránku ve složce, například UserBasedAuthorization.aspx, UrlAuthorizationModule služba požadavek zamítne a budete přesměrováni na přihlašovací stránku. Po přihlášení jako, řekněme, Scott, můžete navštívit libovolnou Membership stránku ve složce s výjimkouCreatingUserAccounts.aspx. Pokud se pokusíte navštívit CreatingUserAccounts.aspx uživatelem přihlášeným jako kdokoli jiný než Tito, dojde k pokusu o neoprávněný přístup, který vás přesměruje zpět na přihlašovací stránku.

Poznámka

Element <location> se musí objevit mimo element konfigurace <system.web> . Pro každý prostředek, jehož nastavení autorizace chcete přepsat, musíte použít samostatný <location> prvek.

Podívejte se, jak seUrlAuthorizationModuleautorizační pravidla používají k udělení nebo odepření přístupu.

Určuje UrlAuthorizationModule , zda se má autorizovat konkrétní identita pro konkrétní adresu URL tak, že se autorizační pravidla adresy URL analyzují po jednom, počínaje od prvního z nich a jejich fungováním směrem dolů. Jakmile se najde shoda, uživateli je udělen nebo odepřen přístup v závislosti na tom, jestli byla nalezena shoda v elementu <allow> nebo <deny> . Pokud se nenajde žádná shoda, uživateli se udělí přístup. Pokud tedy chcete omezit přístup, je nutné použít <deny> prvek jako poslední prvek v konfiguraci autorizace adresy URL. Pokud vynecháte<deny>bude udělen přístup všem uživatelům.

Pokud chcete lépe porozumět procesu, který UrlAuthorizationModule používá k určení autority, podívejte se na ukázková pravidla autorizace adres URL, na která jsme se podívali dříve v tomto kroku. První pravidlo je <allow> prvek, který umožňuje přístup k Titovi a Scottu. Druhé pravidlo je <deny> prvek, který odepře přístup všem. Pokud ho navštíví anonymní uživatel, UrlAuthorizationModule začne dotazem: Je anonymní Scott nebo Tito? Odpověď je samozřejmě Ne, takže pokračuje k druhému pravidlu. Je anonymní v sadě všech? Vzhledem k tomu, že odpověď je zde Ano, <deny> pravidlo se uplatní a návštěvník se přesměruje na přihlašovací stránku. Podobně, pokud Jisun je na návštěvě, UrlAuthorizationModule začíná tím, že se ptá: Je Jisun buď Scott, nebo Tito? Vzhledem k tomu, že není, UrlAuthorizationModule pokračuje druhá otázka, Je Jisun v souboru všech? Ona je, takže i ona má odepřený přístup. A konečně, pokud tito navštíví, první otázka položená v nástroji UrlAuthorizationModule je kladná odpověď, takže Tito má přístup.

Vzhledem k tomu, že UrlAuthorizationModule autorizační pravidla zpracovávají shora dolů a zastavují se při jakékoli shodě, je důležité, aby se konkrétnější pravidla dostala před méně specifická pravidla. To znamená, že pokud chcete definovat autorizační pravidla, která zakazují Jisun a anonymní uživatele, ale povolují všechny ostatní ověřené uživatele, začali byste s nejsefinovanějším pravidlem , které má vliv na Jisun, a pak byste pokračovali méně konkrétními pravidly – která povolují všechny ostatní ověřené uživatele, ale odepírají všem anonymním uživatelům. Následující pravidla autorizace adres URL implementují tuto zásadu tak, že jisun nejprve zamítnou a pak zamítnou anonymnímu uživateli. Všem ověřeným uživatelům kromě Jisunu se udělí přístup, protože žádný z těchto <deny> příkazů se neshoduje.

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

Krok 2: Oprava pracovního postupu pro neautorizované a ověřené uživatele

Jak jsme probrali dříve v tomto kurzu v části Podívejte se na pracovní postup autorizace adresy URL, kdykoli se zobrazí neautorizovaný požadavek, UrlAuthorizationModule přeruší požadavek a vrátí stav HTTP 401 Neautorizováno. Tento stav 401 je změněn na FormsAuthenticationModule stav přesměrování 302, který uživatele odešle na přihlašovací stránku. K tomuto pracovnímu postupu dochází u všech neautorizovaných požadavků, a to i v případě, že je uživatel ověřený.

Vrácení ověřeného uživatele na přihlašovací stránku ho pravděpodobně zmást, protože už je přihlášený k systému. S trochou práce můžeme tento pracovní postup vylepšit přesměrováním ověřených uživatelů, kteří zasílají neoprávněné požadavky, na stránku, která vysvětluje, že se pokusili o přístup ke stránce s omezeným přístupem.

Začněte vytvořením nové ASP.NET stránky v kořenové složce webové aplikace s názvem UnauthorizedAccess.aspx; nezapomeňte tuto stránku přidružit ke Site.master stránce předlohy. Po vytvoření této stránky odeberte ovládací prvek Obsah, který odkazuje na LoginContent ContentPlaceHolder, aby se zobrazil výchozí obsah stránky předlohy. Dále přidejte zprávu, která vysvětluje situaci, a to, že se uživatel pokusil o přístup k chráněnému prostředku. Po přidání takové zprávy UnauthorizedAccess.aspx by deklarativní kód stránky měl vypadat nějak takto:

<%@ 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>

Teď musíme změnit pracovní postup tak, aby se v případě provedení neoprávněného požadavku ověřeným uživatelem odesílaly na UnauthorizedAccess.aspx stránku místo na přihlašovací stránku. Logika, která přesměrovává neautorizované požadavky na přihlašovací stránku, je uložená v privátní metodě FormsAuthenticationModule třídy, takže toto chování nemůžeme přizpůsobit. Můžeme ale na přihlašovací stránku přidat vlastní logiku, která uživatele v případě potřeby přesměruje na UnauthorizedAccess.aspx.

Když objekt FormsAuthenticationModule přesměruje neautorizovaného návštěvníka na přihlašovací stránku, připojí k řetězci dotazu požadovanou neoprávněnou adresu URL s názvem ReturnUrl. Pokud se například neoprávněný uživatel pokusil o návštěvu OnlyTito.aspx, přesměruje ho FormsAuthenticationModule na Login.aspx?ReturnUrl=OnlyTito.aspxadresu . Proto pokud se k přihlašovací stránce dostane ověřený uživatel pomocí řetězce dotazu, který obsahuje ReturnUrl parametr , víme, že se tento neověřený uživatel právě pokusil navštívit stránku, ke které nemá oprávnění k zobrazení. V takovém případě ji chceme přesměrovat na UnauthorizedAccess.aspxadresu .

K tomu přidejte následující kód do obslužné rutiny události přihlašovací stránky Page_Load :

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");
    }
}

Výše uvedený kód přesměruje ověřené a neoprávněné uživatele na UnauthorizedAccess.aspx stránku. Pokud chcete vidět tuto logiku v akci, navštivte web jako anonymní návštěvník a klikněte na odkaz Vytváření uživatelských účtů v levém sloupci. Tím přejdete na ~/Membership/CreatingUserAccounts.aspx stránku, kterou jsme v kroku 1 nakonfigurovali tak, aby umožňovala přístup pouze k Titovi. Vzhledem k tomu, že anonymní uživatelé jsou zakázáni FormsAuthenticationModule , přesměruje nás aplikace zpět na přihlašovací stránku.

V tomto okamžiku jsme anonymní, takže Request.IsAuthenticated se vrátí false a nejsme přesměrováni na UnauthorizedAccess.aspx. Místo toho se zobrazí přihlašovací stránka. Přihlaste se jako jiný uživatel než Tito, například Bruce. Po zadání příslušných přihlašovacích údajů nás přihlašovací stránka přesměruje zpět na ~/Membership/CreatingUserAccounts.aspxadresu . Vzhledem k tomu, že je tato stránka přístupná pouze Titovi, nemáme oprávnění ji zobrazit a jsme okamžitě vráceni na přihlašovací stránku. Tentokrát ale Request.IsAuthenticated vrátí hodnotu true (a ReturnUrl parametr querystring existuje), takže jsme přesměrováni na UnauthorizedAccess.aspx stránku.

Ověřeno, neautorizovaní uživatelé jsou přesměrováni na UnauthorizedAccess.aspx

Obrázek 6: Ověřeno, Neoprávnění uživatelé jsou přesměrováni na UnauthorizedAccess.aspx (Kliknutím zobrazíte obrázek v plné velikosti)

Tento přizpůsobený pracovní postup představuje rozumnější a přímočařejší uživatelské prostředí tím, že zkratuje cyklus znázorněný na obrázku 2.

Krok 3: Omezení funkčnosti na základě aktuálně přihlášeného uživatele

Autorizace adresy URL usnadňuje zadávání hrubých autorizačních pravidel. Jak jsme viděli v kroku 1, s autorizací adres URL můžeme stručně uvést, jaké identity jsou povolené a které mají odepření zobrazení konkrétní stránky nebo všech stránek ve složce. V určitých scénářích ale můžeme chtít povolit všem uživatelům navštívit stránku, ale omezit funkčnost stránky na základě uživatele, který ji navštíví.

Představte si případ webu elektronického obchodování, který umožňuje ověřeným návštěvníkům kontrolovat jejich produkty. Když anonymní uživatel navštíví stránku produktu, uvidí jenom informace o produktu a nebude mít možnost zanechat recenzi. Ověřený uživatel, který navštíví stejnou stránku, by však viděl rozhraní pro kontrolu. Pokud ověřený uživatel ještě nezkontroloval tento produkt, rozhraní by mu umožnilo odeslat revizi; jinak by se jim zobrazila jejich dříve odeslaná recenze. Pokud chcete tento scénář posunout ještě o krok dál, může se na stránce produktu zobrazit další informace a nabídnout rozšířené funkce pro uživatele, kteří pracují pro společnost elektronického obchodování. Stránka produktu může například obsahovat seznam skladových zásob a možnosti pro úpravu ceny a popisu produktu při návštěvě zaměstnancem.

Taková jemně odstupňovaná autorizační pravidla lze implementovat buď deklarativně, nebo programově (nebo prostřednictvím kombinace těchto dvou pravidel). V další části uvidíme, jak implementovat jemně odstupňovanou autorizaci prostřednictvím ovládacího prvku LoginView. Potom prozkoumáme programové techniky. Než se ale podíváme na použití jemně odstupňovaných autorizačních pravidel, musíme nejprve vytvořit stránku, jejíž funkce závisí na uživateli, který ji navštíví.

Pojďme vytvořit stránku se seznamem souborů v určitém adresáři v gridview. Spolu s výpisem názvu, velikosti a dalších informací o jednotlivých souborech bude GridView obsahovat dva sloupce LinkButtons: jeden s názvem Zobrazení a jeden s názvem Delete. Je-li tlačítko Zobrazit OdkazButton bude zobrazen obsah vybraného souboru; Pokud kliknete na Tlačítko Odstranit odkaz, soubor se odstraní. Pojďme nejprve vytvořit tuto stránku tak, aby její funkce zobrazení a odstranění byly dostupné všem uživatelům. V částech Použití ovládacího prvku LoginView a Omezení funkčnosti prostřednictvím kódu programu uvidíme, jak tyto funkce povolit nebo zakázat na základě toho, jak uživatel navštíví stránku.

Poznámka

Stránka ASP.NET, která se chystáme vytvořit, používá ovládací prvek GridView k zobrazení seznamu souborů. Vzhledem k tomu, že se tato série kurzů zaměřuje na ověřování formulářů, autorizaci, uživatelské účty a role, nechci trávit příliš mnoho času diskuzí o vnitřním fungování ovládacího prvku GridView. I když tento kurz obsahuje konkrétní podrobné pokyny pro nastavení této stránky, nezabývá se podrobnostmi o tom, proč byly provedeny určité volby nebo jaký vliv mají konkrétní vlastnosti na vykreslený výstup. Pokud chcete důkladně prošetřit ovládací prvek GridView, přečtěte si řadu kurzů Práce s daty v ASP.NET 2.0 .

Začněte otevřením UserBasedAuthorization.aspx souboru ve Membership složce a přidáním ovládacího prvku GridView na stránku s názvem FilesGrid. V inteligentní značce GridView kliknutím na odkaz Upravit sloupce otevřete dialogové okno Pole. V levém dolním rohu zrušte zaškrtnutí políčka Automaticky generovat pole. Dále přidejte tlačítko Vybrat, tlačítko Odstranit a dvě boundfields z levého horního rohu (tlačítka Vybrat a Odstranit najdete pod typem CommandField). Nastavte vlastnost tlačítka SelectText Vybrat na View a první BoundField HeaderText a DataField vlastnosti na Název. Nastavte druhou vlastnost BoundField HeaderText na Size in Bytes, jeho DataField vlastnost na Length, jeho DataFormatString vlastnost na {0:N0} a jeho HtmlEncode vlastnost na False.

Po konfiguraci sloupců objektu GridView kliknutím na OK zavřete dialogové okno Pole. Z okno Vlastnosti nastavte vlastnost GridView DataKeyNames na FullName. V tomto okamžiku by deklarativní značky GridView měly vypadat takto:

<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 vytvoření značky GridView jsme připraveni napsat kód, který načte soubory v konkrétním adresáři a sváže je s Objektem GridView. Do obslužné rutiny Page_Load události stránky přidejte následující kód:

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();
    }
}

Výše uvedený kód používá DirectoryInfo třídu k získání seznamu souborů v kořenové složce aplikace. MetodaGetFiles() vrátí všechny soubory v adresáři jako pole FileInfo objektů, která je pak vázána na GridView. Objekt FileInfo má mimo jiné řadu vlastností, jako Namejsou , Lengtha IsReadOnly. Jak můžete vidět z jeho deklarativní značky, GridView zobrazí pouze Name vlastnosti a Length .

Poznámka

Třídy DirectoryInfo a FileInfo se nacházejí v System.IO oboru názvů. Proto budete muset buď před těmito názvy tříd zadat jejich názvy oborů názvů, nebo nechat obor názvů importovat do souboru třídy (prostřednictvím using System.IO).

Udělejte si chvilku a přejděte na tuto stránku přes prohlížeč. Zobrazí se seznam souborů umístěných v kořenovém adresáři aplikace. Kliknutím na některé z tlačítek Zobrazit nebo Odstranit odkaz způsobíte zpětné odeslání, ale nedojde k žádné akci, protože jsme ještě nevytvořili potřebné obslužné rutiny událostí.

GridView vypíše soubory v kořenovém adresáři webové aplikace.

Obrázek 7: GridView obsahuje seznam souborů v kořenovém adresáři webové aplikace (kliknutím zobrazíte obrázek v plné velikosti)

Potřebujeme prostředek k zobrazení obsahu vybraného souboru. Vraťte se do sady Visual Studio a přidejte TextBox s názvem FileContents nad Objekt GridView. Nastavte jeho TextMode vlastnost na MultiLine a vlastnosti Columns a Rows na 95 % a 10.

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

Dále vytvořte obslužnou rutinu události pro událost GridView SelectedIndexChanged a přidejte následující kód:

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;
}

Tento kód používá vlastnost GridView SelectedValue k určení úplného názvu vybraného souboru. Interně se na kolekci DataKeys odkazuje za účelem získání objektu SelectedValue, takže je nutné nastavit vlastnost GridView DataKeyNames na Název, jak je popsáno dříve v tomto kroku. TřídaFile se používá ke čtení obsahu vybraného souboru do řetězce, který je pak přiřazen vlastnosti FileContents TextBoxText, čímž se zobrazí obsah vybraného souboru na stránce.

Obsah vybraného souboru se zobrazí v textovém poli.

Obrázek 8: Obsah vybraného souboru se zobrazí v textovém poli (kliknutím zobrazíte obrázek v plné velikosti).

Poznámka

Pokud zobrazíte obsah souboru, který obsahuje značky HTML, a pak se pokusíte zobrazit nebo odstranit soubor, zobrazí se chyba HttpRequestValidationException . K tomu dochází, protože při postbacku se obsah Textového pole odesílá zpět na webový server. Ve výchozím nastavení ASP.NET vyvolá chybu HttpRequestValidationException pokaždé, když se zjistí potenciálně nebezpečný obsah zpětného odeslání, například kód HTML. Pokud chcete zakázat výskyt této chyby, vypněte ověření požadavku na stránku přidáním ValidateRequest="false" do direktivy @Page . Další informace o výhodách ověření požadavku a o tom, jaká opatření byste měli při jeho zakázání provést, najdete v tématu Ověření požadavku – prevence útoků na skripty.

Nakonec přidejte obslužnou rutinu události s následujícím kódem pro událost GridViewRowDeleting:

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);
}

Kód jednoduše zobrazí úplný název souboru, který se má odstranit v textovém FileContents poli , aniž by se soubor skutečně odstranil.

Kliknutím na tlačítko Odstranit se soubor ve skutečnosti neodstraní.

Obrázek 9: Kliknutí na tlačítko Odstranit ve skutečnosti neodstraní soubor (kliknutím zobrazíte obrázek v plné velikosti)

V kroku 1 jsme nakonfigurovali autorizační pravidla adres URL tak, aby anonymním uživatelům zakázala prohlížení stránek ve Membership složce. Abychom mohli lépe vykazovat jemně odstupňované ověřování, povolme anonymním uživatelům navštívit UserBasedAuthorization.aspx stránku, ale s omezenou funkčností. Pokud chcete tuto stránku otevřít, aby ji měli přístup všichni uživatelé, přidejte do Web.config souboru ve Membership složce následující <location> prvek:

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

Po přidání tohoto <location> prvku otestujte nová autorizační pravidla adresy URL odhlášením z webu. Jako anonymní uživatel byste měli mít možnost stránku navštívit UserBasedAuthorization.aspx .

V současné době může stránku navštívit UserBasedAuthorization.aspx každý ověřený nebo anonymní uživatel a zobrazit nebo odstranit soubory. Pojďme to nastavit tak, aby obsah souboru mohli zobrazit jenom ověření uživatelé a soubor mohl odstranit jenom Tito. Taková jemně odstupňovaná autorizační pravidla lze použít deklarativně, programově nebo kombinací obou metod. Pojďme použít deklarativní přístup k omezení, kdo může zobrazit obsah souboru. K omezení toho, kdo může soubor odstranit, použijeme programový přístup.

Použití ovládacího prvku LoginView

Jak jsme viděli v předchozích kurzech, ovládací prvek LoginView je užitečný pro zobrazení různých rozhraní pro ověřené a anonymní uživatele a nabízí snadný způsob, jak skrýt funkce, které nejsou přístupné anonymním uživatelům. Vzhledem k tomu, že anonymní uživatelé nemůžou zobrazit nebo odstranit soubory, musíme textové pole zobrazit FileContents jenom v případě, že stránku navštíví ověřený uživatel. Chcete-li toho dosáhnout, přidejte na stránku ovládací prvek LoginView, pojmenujte ho LoginViewForFileContentsTextBoxa přesuňte FileContents deklarativní značky TextBox do LoginView ovládacího prvku LoggedInTemplate.

<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>

Webové ovládací prvky v šablonách LoginView už nejsou přímo přístupné z třídy kódu na pozadí. Například FilesGrid objekty GridView SelectedIndexChanged a RowDeleting obslužné rutiny událostí aktuálně odkazují na FileContents ovládací prvek TextBox s kódem, jako je:

FileContents.Text = text;

Tento kód však již není platný. Přesunutím textového FileContents pole do textového LoggedInTemplate pole nelze přímo získat přístup. Místo toho musíme použít metodu FindControl("controlId") k programovému odkazu na ovládací prvek. Aktualizujte obslužné FilesGrid rutiny událostí tak, aby odkazily na Textové pole takto:

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

Po přesunutí Textového pole do LoginView LoggedInTemplate a aktualizaci kódu stránky tak, aby odkazovat na TextBox pomocí FindControl("controlId") vzoru, navštivte stránku jako anonymní uživatel. Jak ukazuje obrázek 10, FileContents textové pole se nezobrazuje. Přesto se stále zobrazuje tlačítko Zobrazit odkaz.

Ovládací prvek LoginView vykreslí pouze textové pole FileContents pro ověřené uživatele.

Obrázek 10: Ovládací prvek LoginView vykreslí FileContents pouze textové pole pro ověřené uživatele (kliknutím zobrazíte obrázek v plné velikosti)

Jedním ze způsobů, jak skrýt tlačítko Zobrazit pro anonymní uživatele, je převést pole GridView na TemplateField. Tím se vygeneruje šablona, která obsahuje deklarativní kód pro tlačítko Zobrazit odkaz. Pak můžeme přidat ovládací prvek LoginView do TemplateField a umístit LinkButton do LoginView LoggedInTemplateje , čímž skryjete tlačítko Zobrazit před anonymními návštěvníky. Chcete-li to provést, klikněte na odkaz Upravit sloupce z inteligentní značky GridView a otevřete dialogové okno Pole. Dále vyberte tlačítko Vybrat ze seznamu v levém dolním rohu a potom klikněte na odkaz Převést toto pole na TemplateField. Tím upravíte deklarativní značky pole 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>

V tomto okamžiku můžeme přidat LoginView do TemplateField. Následující kód zobrazuje tlačítko Zobrazit odkaz pouze pro ověřené uživatele.

<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 ukazuje obrázek 11, konečný výsledek není tak hezký, protože sloupec Zobrazení se stále zobrazuje, i když jsou tlačítka odkazu pro zobrazení ve sloupci skrytá. V další části se podíváme na to, jak skrýt celý sloupec GridView (a ne jenom LinkButton).

Ovládací prvek LoginView skryje tlačítka odkazu pro zobrazení pro anonymní návštěvníky.

Obrázek 11: Ovládací prvek LoginView skryje tlačítka odkazu pro zobrazení pro anonymní návštěvníky (kliknutím zobrazíte obrázek v plné velikosti)

Omezení funkčnosti prostřednictvím kódu programu

V některých případech jsou deklarativní techniky nedostatečné k omezení funkčnosti na stránku. Dostupnost určitých funkcí stránky může například záviset na kritériích nad rámec toho, jestli je uživatel, který stránku navštěvuje, anonymní nebo ověřený. V takových případech mohou být různé prvky uživatelského rozhraní zobrazeny nebo skryty programovým způsobem.

Abychom omezili funkčnost prostřednictvím kódu programu, musíme provést dvě úlohy:

  1. Určete, jestli má uživatel, který navštíví stránku, přístup k funkcím, a
  2. Upravte uživatelské rozhraní prostřednictvím kódu programu podle toho, jestli má uživatel přístup k dané funkci.

Abychom si ukázali použití těchto dvou úloh, povolme Titoovi pouze odstranění souborů z Objektu GridView. Naším prvním úkolem je tedy zjistit, jestli tito navštíví stránku. Jakmile to zjistíme, musíme skrýt (nebo zobrazit) sloupec Delete v GridView. Sloupce objektu GridView jsou přístupné prostřednictvím jeho Columns vlastnosti. Sloupec se vykresluje pouze v případě, že je jeho Visible vlastnost nastavená na true (výchozí).

Před vazbou dat na GridView přidejte do Page_Load obslužné rutiny události následující kód:

// 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 jsme probrali v kurzu Přehled ověřování pomocí formulářů , User.Identity.Name vrátí název identity. To odpovídá uživatelskému jménu zadanému v ovládacím prvku Login. Pokud tito navštíví stránku, vlastnost druhého sloupce Visible GridView je nastavena na true; jinak je nastavena na false. Čistý výsledek je, že když někdo jiný než Tito navštíví stránku, buď jiný ověřený uživatel, nebo anonymní uživatel, sloupec Odstranit se nevykreslí (viz obrázek 12); Když však Tito navštíví stránku, zobrazí se sloupec Odstranit (viz obrázek 13).

Odstranit sloupec se nevykreslí, když ho navštíví někdo jiný než Tito (například Bruce).

Obrázek 12: Odstranit sloupec se nevykreslí, když ho navštíví někdo jiný než Tito (například Bruce) (kliknutím zobrazíte obrázek v plné velikosti)

Sloupec odstranění se vykreslí pro Tito.

Obrázek 13: Odstranit sloupec je vykreslen pro Tito (kliknutím zobrazíte obrázek v plné velikosti)

Krok 4: Použití autorizačních pravidel u tříd a metod

V kroku 3 jsme anonymním uživatelům zakázali prohlížení obsahu souboru a zakázali jsme odstranění souborů všem uživatelům kromě Tito. Toho bylo dosaženo skrytím přidružených prvků uživatelského rozhraní pro neautorizované návštěvníky prostřednictvím deklarativních a programových technik. V našem jednoduchém příkladu bylo správné skrytí prvků uživatelského rozhraní jednoduché, ale co složitější weby, kde může existovat mnoho různých způsobů, jak provést stejné funkce? Co se stane, když při omezení této funkce na neautorizované uživatele zapomeneme skrýt nebo zakázat všechny příslušné prvky uživatelského rozhraní?

Snadným způsobem, jak zajistit, aby k určité části funkce nemohl přistupovat neoprávněný uživatel, je vyzdobit danou třídu nebo metodu atributemPrincipalPermission . Když modul runtime .NET používá třídu nebo spustí některou z jejích metod, zkontroluje, zda aktuální kontext zabezpečení má oprávnění k použití třídy nebo spuštění metody. Atribut PrincipalPermission poskytuje mechanismus, pomocí kterého můžeme tato pravidla definovat.

Pojďme si ukázat použití atributu PrincipalPermission v obslužných rutinách gridview SelectedIndexChanged a RowDeleting událostí k zákazu spuštění anonymními uživateli a uživateli jinými než Tito. Jediné, co musíme udělat, je přidat příslušný atribut na každou definici funkce:

[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)
{
    ...
}

Atribut obslužné SelectedIndexChanged rutiny události určuje, že obslužnou rutinu události mohou spouštět pouze ověření uživatelé, kde jako atribut v obslužné rutině RowDeleting události omezuje provádění na Tito.

Pokud se nějak pokusí o spuštění RowDeleting obslužné rutiny události jiný uživatel než Tito nebo se neověřovaný uživatel pokusí spustit obslužnou rutinu SelectedIndexChanged události, modul runtime .NET vyvolá SecurityException.

Pokud kontext zabezpečení nemá oprávnění ke spuštění metody, vyvolá se výjimka zabezpečení.

Obrázek 14: Pokud kontext zabezpečení nemá oprávnění ke spuštění metody, SecurityException je vyvolán (kliknutím zobrazíte obrázek v plné velikosti).

Poznámka

Chcete-li povolit více kontextů zabezpečení pro přístup k třídě nebo metodě, ozdobte třídu nebo metodu atributem PrincipalPermission pro každý kontext zabezpečení. To znamená, že chcete, aby tito i Bruce mohli spustit obslužnou rutinu RowDeleting události, přidejte dvaPrincipalPermission atributy:

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

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

Kromě ASP.NET stránek má mnoho aplikací také architekturu, která zahrnuje různé vrstvy, jako jsou obchodní logika a vrstvy přístupu k datům. Tyto vrstvy se obvykle implementují jako knihovny tříd a nabízejí třídy a metody pro provádění funkcí souvisejících s obchodní logikou a daty. Atribut PrincipalPermission je užitečný pro použití autorizačních pravidel na tyto vrstvy.

Další informace o použití atributu PrincipalPermission k definování autorizačních pravidel pro třídy a metody najdete v příspěvku blogu Scotta GuthriehoPřidání autorizačních pravidel do obchodních a datových vrstev pomocí PrincipalPermissionAttributes.

Souhrn

V tomto kurzu jsme se podívali na to, jak použít autorizační pravidla založená na uživatelích. Začali jsme pohledem na ASP. Rozhraní pro autorizaci adres URL pro NET. U každého požadavku modul ASP.NET UrlAuthorizationModule zkontroluje autorizační pravidla adres URL definovaná v konfiguraci aplikace a určí, jestli je identita oprávněná pro přístup k požadovanému prostředku. Stručně řečeno, autorizace adres URL usnadňuje zadání autorizačních pravidel pro určitou stránku nebo pro všechny stránky v konkrétním adresáři.

Autorizační architektura adres URL používá autorizační pravidla na základě stránky po stránce. Při autorizaci adresy URL má žádající identita oprávnění pro přístup ke konkrétnímu prostředku, nebo ne. Mnoho scénářů však vyžaduje podrobnější pravidla autorizace. Místo definování toho, kdo má povolený přístup ke stránce, možná budeme muset umožnit přístup ke stránce všem uživatelům, ale aby zobrazovali jiná data nebo nabízeli různé funkce v závislosti na tom, který uživatel stránku navštíví. Autorizace na úrovni stránky obvykle zahrnuje skrytí určitých prvků uživatelského rozhraní, aby se zabránilo neoprávněným uživatelům v přístupu k zakázaným funkcím. Kromě toho je možné použít atributy k omezení přístupu ke třídám a provádění jeho metod pro určité uživatele.

Šťastné programování!

Další čtení

Další informace o tématech probíraných v tomto kurzu najdete v následujících zdrojích informací:

O autorovi

Scott Mitchell, autor několika knih o ASP/ASP.NET a zakladatel 4GuysFromRolla.com, pracuje s webovými technologiemi Microsoftu od roku 1998. Scott pracuje jako nezávislý konzultant, školitel a spisovatel. Jeho nejnovější kniha je Sams Teach Yourself ASP.NET 2.0 in 24 Hours. Scotta můžete zastihnout na mitchell@4guysfromrolla.com nebo prostřednictvím jeho blogu na http://ScottOnWriting.NETadrese .

Zvláštní poděkování

Tato série kurzů byla zkontrolována mnoha užitečnými recenzenty. Chcete si projít moje nadcházející články na WEBU MSDN? Pokud ano, dejte mi čáru na mitchell@4GuysFromRolla.comadresu .

PředchozíDalší