В обычных условиях, когда мы занимаемся управлением правами доступа, мы сохраняем базовую информацию пользователя после правильного входа в сессии и получаем её каждый раз, когда пользователь запрашивает данные страницы или интерфейса в будущем
Сессия, чтобы проверить и сравнить, вошёл ли он в систему и может ли он получить доступ к текущей странице.
Принцип Session заключается в создании SessionID на серверной стороне, соответствующего сохранённым пользовательским данным, и SessionID хранится в cookie, и клиент будет носить его с собой каждый раз при запросе
Cookie — сервер находит данные, хранящиеся на стороне сервера, на основе идентификатора сессии в куки.
FormsAuthentication предоставляет Microsoft для нас, разработчиков, для использования для аутентификации. С помощью этой аутентификации мы можем хранить имя пользователя и часть пользовательских данных в файлах cookie,
Базовая идентификация и аутентификация роли легко достигается с помощью базовых настроек условий.
Результат здесь — реализация ролевого контроля доступа с использованием системного Authorize без использования членства.
1. Создать заявку
После входа пользователь в заявку сохраняется его ID и соответствующая роль (для нескольких ролей, разделённые).
Зашифруйте тикет с помощью FormsAuthentication.Encrypt.
Храните зашифрованный тикет в cookie Response (клиенту js не нужно читать этот файл, поэтому лучше установить HttpOnly=True, чтобы предотвратить атаки браузера со стороны кражи и подделки файлов cookie). Так вы сможете прочитать его через cookie Request в следующий раз.
Простая демонстрация выглядит следующим образом:
bool isPersistent, //стоит ли сохранять (устанавливается по необходимости, если установлен на persistence, при отправке cookie должна быть установлена настройка Expires файла cookie)
Шестой параметр FormsAuthenticationTicket хранит userData строки типа, где хранится идентификатор роли текущего пользователя, разделённый запятой.
При входе в систему с имя пользователя «test» на клиенте появляется cookie log
2. Получите информацию о сертификации
После входа на странице содержимого мы можем получить информацию о uname через User.Identity.Name текущего запроса или расшифровать куки в запросе, чтобы получить тикет, а затем получить 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. Если вы хотите гибко настроить роли Controller и Action Permit Access, вы можете настроить метод OnAuthorization в оверрайде AuthorizeAttribute, где используется этот метод
Прочитайте разрешённый идентификатор роли на текущей странице и проверьте его согласно RoleID текущего пользователя. Таким образом, реализуется гибкая конфигурация роли.
4. Информация из тикета в конечном итоге сохраняется в куки, а безопасность остаётся на ваше усмотрение, лично я считаю, что лучше хранить UserID и RoleID в сессии.
|
Опубликовано 19.07.2018 17:31:14
|
|
|
