При нормални обстоятелства, когато правим управление на правата за достъп, ще запазим основната информация на потребителя след правилното влизане в сесията и ще я получаваме всеки път, когато потребителят поиска данни от страница или интерфейс в бъдеще
Сесия, за да се види и сравни дали е влязъл и дали може да достъпи текущата страница.
Принципът на Session е да генерира SessionID на сървърната страна, съответстващ на съхранените потребителски данни, а SessionID се съхранява в бисквитка, като клиентът го носи със себе си всеки път, когато бъде поискан
Cookie, сървърът намира данните, съхранени от страна на сървъра, въз основа на session ID в бисквитката.
FormsAuthentication се предоставя от Microsoft за нас, разработчиците, за да ги използваме за удостоверяване. Чрез тази автентикация можем да съхраняваме потребителското име и някои потребителски данни в бисквитки,
Основната идентификация и удостоверяване на ролята може лесно да се постигне чрез основни настройки на условията.
Резултатът, който трябва да се постигне тук, е да се реализира контрол на достъпа, базиран на роли, използвайки системния Authorize без използване на членство.
1. Създайте тикет
След като потребителят влезе, ID-то на потребителя и съответната роля (за няколко роли, разделени) се съхраняват в тикета.
Криптирайте тикета с FormsAuthentication.Encrypt.
Съхранявайте криптирания билет в бисквитката Response (клиентът js не е нужно да чете тази бисквитка, затова е най-добре да се зададе HttpOnly=True, за да се предотврати кражба и фалшифициране на браузърни атаки). По този начин следващия път можете да го прочетете от бисквитките "Заявка".
Едно просто демо е следното:
bool isPersistent, //дали да се запази (зададен според нуждите, ако е настроен на persistence, настройката Expires на бисквитката трябва да се зададе при изпращане на бисквитка)
Шестият параметър на FormsAuthenticationTicket съхранява userData на типа низа, където се съхранява ролевият ID на текущия потребител, разделен със запетая.
При влизане с потребителско име "test", на клиента се появява лог бисквитка
2. Получаване на информация за сертификация
След като влезем, на страницата със съдържание, можем да получим информацията за uname чрез User.Identity.Name на текущата заявка, или можем да декриптираме бисквитката в заявката, за да получим тикета, и след това да получим uname и userData (т.е. предварително съхранената информация за role ID) от него.
3. Реализиране на контрол на достъпа чрез анотационни атрибути
Конфигуриране Активиране на удостоверяване на форми и управление на роли в web.config
Когато добавяме анотационни свойства към Controller и Action, откъде получаваме зададената роля? Тъй като не използваме автентикация на базата на членство, ще създадем и персонализиран RoleProvider. Името е CustomRoleProvider, което е наследено от RoleProvider. Ето как създавате собствен CustomRoleProvider.cs файл в папката Helper под MVCApp.
В RoleProvider има много абстрактни методи и ние прилагаме метода GetRolesForUser само за получаване на потребителски роли. Ролята на потребителя тук може да бъде заявена от базата данни според получения потребителски ID или според тази, съхранена в сесията или в бисквитката. Тук вече съм съхранил ролята в userData на тикета, така че нека я вземем от тикета.
Ако е необходимо, добавете атрибути за анотация към валидирания контролер или действие, например това действие позволява достъп само с RoleID 1, 2 или 3, а текущият потребителски RoleID е (7, 1, 8), което означава, че потребителят има право на достъп.
P.S. :1. Тикетът се съхранява в момента на изтичане на бисквитките, и ако браузърът е затворен, за да запомни текущия тикет, параметрите могат да се зададат при стартиране на FormsAuthenticationTicket.
2. Получаването на Role може да се чете директно от базата данни, без да се съхранява в userData на тикета, а userData може да съхранява друга информация.
3. Ако искате гъвкаво да конфигурирате ролите за разрешен достъп на контролера и действието, можете да персонализирате метода OnAuthorization в AuthorizeAttribute override, в който се използва методът
Прочетете ролевия ID, който е разрешен на текущата страница, и го проверете според RoleID на текущия потребител. По този начин се реализира гъвкавата конфигурация на ролята.
4. Информацията в тикета в крайна сметка се съхранява в бисквитката, а сигурността остава на ваше преценение, лично аз мисля, че е по-добре да се съхраняват UserID и RoleID в сесията.
|
Публикувано в 19.07.2018 г. 17:31:14 ч.
|
|
|
