Jistě sami naleznete několik scénářů ve vlastní aplikaci, kdy zjistíte, že je dobré znát právě přihlášeného uživatele. Ať už je to z důvodu, že mu chcete udělat radost a přivítat jej oslovením, nabídnout mu něco navíc, co nepřihlášenému nemůžete, nebo mu jenom ušetřit práci s vyplňováním informací ve formuláři (příkladem mohou být e-shopy). Z toho důvodu je k dispozici Membership provider. Na druhé straně ovšem stojí otázka bezpečnosti citlivých dat. Snad každá lepší aplikace má svoje administrační rozhraní, ke kterému by měli mít přístup pouze oprávnění uživatelé a v takových situacích nám nebude stačit vědět pouze to, že daný uživatel je přihlášen. Budeme chtít uživatele přiřazovat do jednotlivých rolí, abychom jim zpřístupnili pouze tu "správnou" část aplikace, ve které má smysl, aby se pohybovali a činili nějaké úkony.

K zajištění tohoto úkolu nám poslouží právě Role provider. Ten umožňuje k založeným uživatelům přiřazovat role. V tomto ohledu se fantazii meze nekladou, a tak jeden uživatel, může být členem hned několika rolí a samozřejmě záleží jen na našem uvážení, zda potom takový uživatel bude mít dostatečná práva pro činnosti, které má vykonávat, nebo naopak nebude mít práv příliš mnoho. A to hlavně z toho důvodu, že podle těchto rolí je řízen přístup k jednotlivým zdrojům (stránkám, prvkům) naší aplikace.

Role uživatelů

Přiřazování

Když jsem se minule zmiňoval o velké podpoře v oblasti připravených uživatelským prvků, které postačovalo umístit na stránku a téměř vše bylo hotovo, v případě role providera je tomu naopak. Pro přiřazení role uživatelům musíme sáhnout do vlastních řad a prvky si vytvořit sami, případně můžeme využít možností již zmíněného nástroje Web site administration tool.

Ověřování

K práci s rolemi používáme, stejně jako u ostatních providerů, statickou třídu, tentokráte pojmenovanou Roles. K ověřování příslušnosti uživatele do role, můžeme použít ovšem hned tři možnosti, první z nich je metoda Roles.IsUserInRole(string role), která vezme aktuálně přihlášeného uživatele a ověří jej proti předané roli. Druhou možností je opět stejně nazvaná metoda, ale se dvěma parametry Roles.IsUserInRole(string username, string role) umožňující ověřit příslušnost jakéhokoli uživatele, zda je členem dané role. Poslední možností je použít vlastnost User (objektu Page nebo HttpContextu) a metodu, jak jinak, opět nazvanou IsUserInRole.

Na tomto místě je dobré se zmínit o tom, že kontrolovat přístup ke zdrojům nemusíme dělat jen my, ale tuto úlohu za nás plní i některé uživatelské prvky. Jako dobrý příklad bych mohl zmínit TreeView kontrol napojený na Site map provider s povolenou vlastností securitytrimmingenabled. Pokud je pak u položky menu vyplněna vlastnost Roles, porovnává se tato s rolemi přiřazenými pro uživatele a v případě, že daný uživatel nemá oprávnění na danou položku, tato se mu nezobrazí.

Nastavujeme oprávnění přístupu

V okamžiku, kdy jsem se v minulém odstavci zmiňoval o oprávněních uvědomil jsem si, že vlastně ještě nevíme, jak takové oprávnění nastavit. Samozřejmě to není nic těžkého a jedná se o jednoduchý zásah do konfiguračního souboru aplikace. V části pojmenované // můžeme specifikovat uživatele nebo role, které mají přístup do které části aplikace a do kterých jim má být přístup odmítnut. Jak se jistě dozvíte i odjinud, konfigurační soubor může být umístěn v každé složce a může obsahovat tyto informace, případně můžete mít pouze jeden konfigurační soubor a specifikovat element location s atributem path, který určí příslušný soubor nebo adresář, pro který budou platit nastavení. Níže se nachází část konfiguračního souboru, který umožní přístup anonymním uživatelům k souboru logon.aspx, aby se mohli přihlásit k aplikaci.

V závislosti na tom, jak máme strukturován web, tak můžeme povolovat a zakazovat přístup uživatelům, ale spíše předpokládám, že se budeme snažit nastavovat oprávnění právě skupinám. Tudíž elementy, které nás budou zajímat jsou Nebo můžeme využít zástupných znaků * pro všechny uživatel a ? pro anonymní uživatele.

bezpečná aplikace

Právě jsme si dokázali, že zabezpečit aplikaci a nastavit oprávnění pro jednotlivé uživatele a role nemusí být vůbec náročné. Samozřejmě je nutné zminit, že to již bylo možné použít v .NETu 1.0 nebo 1.1, ovšem nikoli s takovou variabilitou. Neboť nesmíme zapomínat na to, co je hlavním důvodem a účelem pro použití provider patternu a tou je nezávislost, možnost změny. Také z toho důvodu je nutné připomenout, ža jako výchozí provider je nastaven AspNetSqlProfileProvider a pokud jej chceme změnit za jiný, můžeme tak učinit v konfiguračním souboru. Jako mávnutím kouzelným proutkem tak můžeme přebírat nastavení z Active directory nebo například xml souboru.