Jak zabezpečit aplikaci v ASP.NET – autentizace pomocí formuláře
V minulém díle seriálu o bezpečnosti v ASP.NET jste se dozvěděli, že ASP.NET podporuje čtyři základní režimy autentizace uživatelů. Dnes vám podrobně popíši režim autentizace pomocí formuláře, který budete s velkou pravděpodobností používat na svých stránkách nejčastěji.
Jak jsem již naznačil v minulém díle seriálu, nastavení způsobu autentizace se provede v souboru web.config, který se nachází v kořenovém adresáři aplikace. Dále může být tento soubor umístěn ve vnořených podadresářích a v tomto případě se provedené volby týkají adresáře (a podadresářů v něm vnořených), ve kterém je konfigurační soubor umístěn. Pro konfiguraci režimu autentizace Form je třeba nastavit několik údajů právě v souboru web.config, vytvořit formulář pro přihlašování a vytvořit kód pro jeho zpracování. Veškeré ukázky obslužného kódu budou napsány v jazyce C#, ale zcela určitě vám nebude činit větší potíže přepsat kód do jakéhokoli jiného jazyka.
Pro základní nastavení autentizace v režimu Form je třeba provést několik nastavení v souboru web.config. Jedná se o sekci authentication, jejíž význam byl popisován v článku Jak zabezpečit aplikaci v ASP.NET, a o vnořenou sekci Forms, jejíž popis bude následovat.
|
Parametr name určuje jméno „autentizačního cookie“, pokud je tento parametr vynechán ,je použito implicitní jméno .ASPXAUTH. Pokud běží na jednom serveru více web aplikací, je nutné v souboru web.config zajistit, aby použitá jména byla unikátní. Do jistých potíží se tak můžete dostat v případě umístění vašich stránek na webhostingu, kdy je jistá šance, že se „trefíte“ do jména, které použil už někdo jiný. Je to sice nepříjemná situace, ale jediné, co vám mohu doporučit, je volit dostatečně složitá jména.
Parametr loginUrl určuje adresu, na kterou bude návštěvník přesměrován v případě, že není přihlášen (neexistuje autentizační cookie). Standardní hodnota je default.aspx.
Parametr protection určuje způsob ochrany autentizačního cookies. Standardní a současně doporučená hodnota tohoto parametru je All.
V parametru timeout je možné specifikovat čas v minutách, po který je autentizace platná. Standardní hodnota je 30 sekund. Pokud však použijete při přihlášení tzv. perzistentní cookies, je tento parametr ignorován.
A konečně parametr path určuje cestu v aplikaci, pro kterou je autentizační cookie platné. Standardní hodnota je „/“ (slash). Pokud budete specifikovat nějakou další cestu, mějte na paměti, že je třeba cestu zapisovat case-sensitive.
Nechce-li se vám editovat soubor web.config ručně, a zápasit s malými a velkými písmeny, můžete pro editaci použít Hunter Stone Web.Config Editor, o kterém jsme psali v článku Editor konfiguračních souboru .NET.
Při přihlašování pomocí formuláře existuje mnoho způsobů, jak ověřit identitu uživatele. Seznámím vás se třemi způsoby, které považuji za nejčastěji používané.
- ověření proti souboru web.config
- ověření proti souboru XML
- ověření proti SQL databázi
Jistě najdete několik dalších způsobů, jak ověřit uživatele proti čemukoli. Postup je vždy naprosto shodný, stačí zpracovat údaje z formuláře, ověřit jejich pravdivost na místě, kde máme uloženy informace o uživatelích, a v kladném případě dát ASP.NETu na vědomí, že je uživatel přihlášen. Dnes se budeme věnovat ověření proti souboru web.config.
Přihlašovací formulář
Pro přihlášení pomocí formuláře je nutné si tento formulář nejprve vytvořit. Formulář bude obsahovat políčko pro zadání jména a hesla a tlačítko pro odeslaní formuláře. Uživateli však zůstane skryto několik dalších prvků a to sice validátory, které nedovolí odeslat formulář bez vyplnění, a také text, který se zobrazí při neúspěšném přihlášení. Formulář uložíme do souboru login.aspx a kód pro jeho zpracovaní bude uložen v souboru login.aspx.cs.
Vzhled formuláře můžete vytvořit například ve vývojovém prostředí Microsoft ASP.NET Web Matrix, o kterém jsme psali v článku WEB MATRIX Vývojové prostředí pro ASP.NET a které je zdarma. Já osobně jsem jej vytvořil v komerčním vývojovém prostředí Visual Studio.NET, které však může být pro některé z vás nedostupné. Formulář může vypadat například takto:
Formulář obsahuje dvě textová pole pro zadání jména a hesla. K těmto dvěma textovým polím jsou přiřazeny validátory, které znemožní odeslání formuláře bez vyplnění obou položek. Podrobně si o validátorech můžete přečíst v článku ASP.NET – schvalovací prvky.
Zdrojový kód formuláře – login.aspx:
|
Ošetření události po kliknutí na tlačítko přihlásit:
|
Formulář bude pro všechny tři popisované způsoby ověření identický a měnit se bude pouze část, ve které dochází k ověřování správnosti zadaných údajů (autentizaci).
Obsluha událostí z formuláře
Jedinou událostí, kterou budeme muset pro správnou činnost obsloužit, je kliknutí na tlačítko Přihlásit. Způsob, kterým tuto událost obsloužíme, bude záviset na místě uložení údajů o uživateli. V konečném důsledku však musíme po ověření dát ověřovacímu stroji ASP.NET na vědomí, že uživatel je ověřen. Pro toto oznámení použijme metodu SetAuthCookie nebo RedirectFromLoginPage ze třídy FormsAuthentication, která je umístěna ve jmenném prostoru System.Web.Security. Obě metody fungují naprosto stejně, ale metoda RedirectFromLoginPage umí navíc přesměrovat uživatele zpět na stánku, na kterou uživatel chtěl přistoupit předtím, než byl donucen k autentizaci.
|
Metody mají dva parametry. Do parametru userName se uvádí uživatelské jméno autorizovaného uživatele. Podle toho, jakou hodnotu předáme v parametru createPersistentCookie, bude cookies persistentní či nikoli.
Pokud bude parametr nabývat hodnoty false, bude cookie platné po dobu nastavenou v souboru web.config. Pokud dojde k ukončení prohlížeče, bude autentizační cookie ostraněno.
Jestliže použijete hodnotu true, bude vytvořeno cookie, které bude platné stále, a to dokonce i při restartu prohlížeče. Jediný způsob, jak tento typ autentizačního cookies odstranit, je provést odhlášení způsobem, který je popsán níže.
Pokud budete chtít umožnit uživateli odhlášení, je třeba zajistit vykonání metody SignOut ze třídy FormsAuthentication ve jmenném prostoru System.Web.Security. Metoda nemá žádné parametry a způsobí odstranění autentizačního cookie:
|
Ověření v souboru web.config
Při ověřování proti souboru web.config se uživatelská jména a hesla ukládají do sekce credentials, která je vnořena v sekci forms.
|
Pomocí parametru passwordFormat zvolíte způsob zašifrování uloženého hesla. Při použití hodnoty Clear nejsou hesla nijak šifrována. Pokud však použijete parametr SHA1 či MD5, bude použit příslušný šifrovací algoritmus. Podrobný popis těchto algoritmů najdete například v MSDN Library.
Uživatelská jména a hesla se ukládají do sekce user, kde se v parametru name uvede přihlašovací jméno uživatele a v parametru password jeho heslo.
Pokud v této fázi zkusíte přistoupit na jakoukoli stránku aplikace, zjistíte, že se bez problémů dostanete kamkoli, a to bez zobrazení přihlašovacího formuláře. Je to proto, že je stále povolen přístup ke stránkám aplikace všem uživatelům a anonymní uživatel tedy může k požadované stránce přistoupit. Aby autentizace začala skutečně fungovat, je třeba do souboru web.config doplnit sekci authorization, ve které zakážete přístup anonymnímu uživateli.
|
Sekce authorization, která je vnořena do sekce systém.web, umožňuje řídit práva uživatelů a dokonce omezovat i protokoly, které může daný uživatel použít. Lze tak snadno a jednoduše například zakázat uživateli poslat na server data (metoda POST), ale současně mu umožnit data ze serveru získat.
Pro úplnost a přehlednost zde uvedu příklad souboru web.config, který je použit v ukázkovém příkladu:
|
Pokud vás teď trápí problém jak získat zašifrovaná hesla algoritmem SHA1 či MD5, mám tu pro vás jednoduché řešení. Na adrese http://aspx1.podklady/1999-2008.interval.cz/kopp/hash/ najdete online aplikaci, která zadaný text zašifruje příslušnými algoritmy a vrátí jej zpět ve formuláři.
Samozřejmě jsem nezapomněl na možnost stažení dnešních zdrojových kódů přihlašovacího formuláře. A na co se můžete těšit v dalším díle? Jak jsem naznačil již v úvodu článku, bude to ověření identity uživatele proti XML souboru.
Starší komentáře ke článku
Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.
Mohlo by vás také zajímat
-
Zvýšení výkonu WiFi signálu: Jak a proč používat WiFi zesilovače
28. června 2023 -
Vaše pošta může být špatně nastavena – svěřte ji profesionálům
13. července 2023
Nejnovější
-
Jak zvýšit CTR vašeho e-mail marketingu
9. září 2024 -
Znovuuvedení domény .AD
5. září 2024