За звичайних обставин, коли ми займаємося управлінням правами доступу, ми зберігаємо базову інформацію користувача після правильного входу в сесії і отримуємо її щоразу, коли користувач запитує дані сторінки чи інтерфейсу в майбутньому
Сесія, щоб перевірити та порівняти, чи він увійшов у систему і чи може він отримати доступ до поточної сторінки.
Принцип Session полягає в тому, щоб генерувати SessionID на стороні сервера, що відповідає збереженим користувацьким даним, і SessionID зберігається у файлі cookie, і клієнт носить його з собою щоразу, коли його запитують
Cookie, сервер знаходить дані, що зберігаються на стороні сервера, на основі ідентифікатора сесії в файлі cookie.
FormsAuthentication надає Microsoft для нас, розробників, для автентифікації. Завдяки цій автентифікації ми можемо зберігати ім'я користувача та деякі дані користувача у файлах cookie,
Базова автентифікація ідентичності та ролі може бути легко досягнута за допомогою базових налаштувань умов.
Результат, якого потрібно досягти, полягає в реалізації контролю доступу на основі ролей за допомогою системного Authorize без використання членства.
1. Створіть заявку
Після входу користувача ID користувача та відповідна роль (для кількох ролей, розділені) зберігаються у тікету.
Зашифруйте заявку за допомогою FormsAuthentication.Encrypt.
Зберігайте зашифрований тікет у cookie Response (клієнту js не потрібно читати це cookie, тому найкраще встановити HttpOnly=True, щоб запобігти атакам браузера з крадіжкою та підробкою cookie). Таким чином, наступного разу ви зможете прочитати його з cookie Request.
Просте демо виглядає так:
bool isPersistent, //чи зберігати (встановлено за потреби, якщо встановлено на persistence, налаштування Expires cookie має бути встановлене при відправці файлу cookie)
Шостий параметр FormsAuthenticationTicket зберігає userData рядка типу, де зберігається ідентифікатор ролі поточного користувача, розділений комою.
При вході з ім'ям користувача «test» на клієнті з'являється cookie log
2. Отримати інформацію про сертифікацію
Після входу на сторінці контенту ми можемо отримати інформацію про uname через User.Identity.Name поточного запиту, або розшифрувати файл cookie у запиті, щоб отримати тікет і отримати uname та userData (тобто раніше збережену інформацію про ідентифікатор ролі) з нього.
3. Реалізувати контроль доступу за дозволом через атрибути анотації
Налаштуйте увімкнути аутентифікацію форми та управління ролями у web.config
Коли ми додаємо властивості анотації до Controller і Action, звідки ми отримуємо задану роль (Role)? Оскільки ми не використовуємо автентифікацію на основі членства, ми також створимо власного RoleProvider. Назва — CustomRoleProvider, яка успадкується від RoleProvider. Ось створення власного CustomRoleProvider.cs файлу у папці Helper під MVCApp.
У RoleProvider існує багато абстрактних методів, і ми реалізуємо метод GetRolesForUser лише для отримання ролей користувачів. Роль користувача тут може бути запитана з бази даних відповідно до отриманого ідентифікатора користувача або тієї, що зберігається в сесії чи в файлі cookie. Тут я вже зберіг роль у userData тикету, тож давайте візьмемо її з тикету.
За потреби додайте атрибути анотації до перевіреного контролера або дії, наприклад, ця дія дозволяє доступ лише з RoleID 1, 2 або 3, а поточний RoleID користувача — (7, 1, 8), що означає, що користувач має право на доступ.
P.S. :1. Тікет зберігається у час закінчення терміну дії cookie, і якщо браузер закритий, щоб запам'ятати поточний тикет, параметри можна встановити при запуску FormsAuthenticationTicket.
2. Отримання Ролі можна читати безпосередньо з бази даних без збереження в userData заявки, а userData може зберігати іншу інформацію.
3. Якщо ви хочете гнучко налаштувати ролі дозволеного доступу контролера та дії, ви можете налаштувати метод OnAuthorization у перевизначенні AuthorizeAttribute, де використовується цей метод
Прочитайте дозволений ідентифікатор ролі на поточній сторінці та перевірте його відповідно до RoleID поточного користувача. Таким чином реалізується гнучка конфігурація ролі.
4. Інформація в тікет зрештою зберігається в cookie, а безпека залишається на ваш розсуд, особисто я вважаю, що краще зберігати UserID і RoleID у сесії.
|
Опубліковано 19.07.2018 17:31:14
|
|
|
