Za normálních okolností, když spravujeme přístupová práva, uložíme základní informace uživatele po správném přihlášení v relaci a získáme je pokaždé, když uživatel požádá o data stránky nebo rozhraní v budoucnu
Relace, kde se zjistí a porovná, zda je přihlášený a zda má přístup k aktuální stránce.
Princip Session spočívá v tom, že na straně serveru vygeneruje SessionID odpovídající uloženým uživatelským datům, přičemž SessionID je uloženo v cookie, a klient jej s sebou přenáší pokaždé, když je požádáno
Cookie, server najde data uložená na straně serveru na základě ID relace v cookie.
FormsAuthentication poskytuje Microsoft pro nás vývojáře k použití pro autentizaci. Díky této autentizaci můžeme uživatelské jméno a některá uživatelská data uložit do cookies,
Základní ověřování identity a role lze snadno dosáhnout pomocí základních nastavení podmínek.
Efektem, kterého lze tímto dosáhnout, je implementace řízení přístupu založeného na rolích pomocí systémem poskytovaného Authorize bez použití členství.
1. Vytvořit tiket
Po přihlášení uživatele jsou do tiketu uloženy jeho ID a odpovídající role (pro více rolí, oddělené).
Zašifrujte ticket pomocí FormsAuthentication.Encrypt.
Uložený šifrovaný tiket je uložen v cookie Response (klient js nemusí tento cookie číst, proto je nejlepší nastavit HttpOnly=True, aby se zabránilo útokům prohlížeče, které by mohly cookies ukrást a falšovat). Tímto způsobem si ho příště můžete přečíst z cookie Request.
Jednoduché demo je následující:
bool isPersistent, //zda zachovat (nastaveno dle potřeby, pokud je to nastaveno na perzistenci, musí být při odeslání cookie nastaveno nastavení Expires cookies)
Šestý parametr FormsAuthenticationTicket ukládá userData řetězce typu, kde je uloženo ID role aktuálního uživatele, oddělené čárkou.
Při přihlášení s uživatelským jménem "test" se na klientovi objeví log cookie
2. Získat certifikační informace
Po přihlášení na stránce obsahu můžeme získat informace o uname přes User.Identity.Name aktuálního požadavku, nebo můžeme dešifrovat cookie v požadavku pro získání tiketu a poté získat uname a userData (tedy dříve uložené informace o ID role) z něj.
3. Realizace řízení přístupu k oprávněním prostřednictvím atributů anotací
Konfigurujte povolení autentizace formulářů a správu rolí ve web.config
Když přidáváme vlastnosti anotací do Controller a Action, kde získáme nastavenou roli? Protože nepoužíváme autentizaci založenou na členství, vytvoříme také vlastního RoleProvidera. Název je CustomRoleProvider, který je zděděn od RoleProvider. Zde je vytvoření vašeho vlastního CustomRoleProvider.cs souboru ve složce Helper pod MVCApp.
V RoleProvider existuje mnoho abstraktních metod a my používáme pouze metodu GetRolesForUser pro získání rolí uživatelů. Uživatelská role zde může být dotazována z databáze podle získaného uživatelského ID, nebo podle toho, které je uloženo v relaci či v cookie. Zde už mám roli uloženou v userData tiketu, takže ji pojďme získat z tiketu.
Pokud je to nutné, přidejte atributy anotací k ověřenému řadiči nebo akci, například tato akce umožňuje přístup pouze s RoleID 1, 2 nebo 3 a aktuální uživatelské RoleID je (7, 1, 8), což znamená, že uživatel má právo na přístup.
P.S. :1. Ticket je uložen v době expirace cookie a pokud je prohlížeč zavřený, aby si zapamatoval aktuální ticket, parametry lze nastavit při instanci FormsAuthenticationTicket.
2. Získání role lze číst přímo z databáze, aniž by bylo uloženo v userData ticketu, a userData mohou ukládat další informace.
3. Pokud chcete flexibilně konfigurovat povolené přístupové role Controller a Action, můžete si v přepisu AuthorizeAttribute přizpůsobit metodu OnAuthorization, kde se metoda používá
Přečtěte si ID role, které je povoleno na aktuální stránce, a zkontrolujte ho podle RoleID aktuálního uživatele. Tímto způsobem je realizována flexibilní konfigurace role.
4. Informace v tiketu jsou nakonec uloženy v cookie a bezpečnost je stále na vašem uvážení, osobně si myslím, že je lepší uložit UserID a RoleID do relace.
|
Zveřejněno 19.07.2018 17:31:14
|
|
|
