Vue реализует внешний контроль разрешений

Vue.js

Блок-схема входа и разрешений

предисловие

Прежде всего, определенный нами контроль разрешений разделен на три части, которые разделены на более тонкие точки в зависимости от степени детализации:

  • Контроль разрешений на вход
  • Контроль разрешений страницы
    • Доступны ли страницы в меню
    • Отображается ли контроль разрешений кнопок (добавить, удалить, изменить, проверить) на странице
  • Контроль разрешений интерфейса

1. Контроль разрешений на вход

Контроль доступа к логину — это проверка пользователя. После того, как пользователь успешно войдет в систему, фон вернет токен, и каждый раз, когда интерфейс делает запрос интерфейса, он должен приносить этот токен. После получения токена в фоновом режиме его можно судить.Если токен существует и срок его действия не истек, к нему можно получить доступ. Если токен не существует или фон считает, что срок его действия истек, он перейдет на страницу входа и попросит пользователя снова войти в систему, чтобы получить токен.

做法一

В обратном вызове успешного входа пользователя токен, возвращенный фоном, сохраняется непосредственно в localStorage, а затем синхронно настраиваются параметры запроса по умолчанию, чтобы вынуть токен, поместить его в заголовки и передать его фону. код показывает, как показано ниже:

   let axiosOptions = {
     method,
     url,
     data,
     timeout,
     // 'arraybuffer', 'blob', 'document', 'json', 'text', 'stream'。default json
     responseType,
     // 请求头内追加authToken属性
     headers: {
       authtToken: window.localStorage.getItem(`base/token?`)
     }
   }

做法二

В текущем проекте для установки перехвата перед отправкой запроса используется axios.interceptors.request.use, а токен напрямую вставляется в req.headers.authToken в качестве глобального прохода. код показывает, как показано ниже:

// axios.interceptors.request.use 请求拦截：配置发送请求的信息
// axios.interceptors.response.use 响应拦截：配置请求回来的信息

axios.interceptors.request.use(req => {
  req.headers.authToken = window.localStorage.getItem(`base/token?`)
  return req
}, error => {
  return Promise.reject(error)
})

Очки знаний, связанные с входом в систему

  • vuex + localStorage: постоянно хранить токены локально через vuex + localStorage (токен: ключ, созданный сервером для уникальной идентификации пользователя).
  • axios: запросить токен проверки перехвата, вы можете использовать axios API: axios.interceptors.request.use или добавить токен в заголовок запроса, добавив параметры по умолчанию.

2. Управление доступом к странице

Как упоминалось выше, существует два типа контроля доступа к странице:

  • Доступны ли страницы в меню
  • Отображается ли контроль разрешений кнопок (добавить, удалить, изменить, проверить) на странице

先看菜单的页面访问权限

Реализация доступа страницы может быть разделена на следующие программы:

  • Вариант 1. Инициализация заключается в монтировании всех маршрутов и проверке каждого маршрута перед переходом
  • Вариант 2: монтировать только маршрут, принадлежащий текущему пользователю.Если пользователь выполняет обязательный доступ через URL-адрес, он напрямую вводит 404, что эквивалентно управлению из источника.

Недостаток первого очевиден: делать проверку каждый раз при скачке маршрута — пустая трата вычислительных ресурсов, кроме того, для маршрутов, к которым пользователи не имеют доступа, теоретически их не следует монтировать. Последнее решает вышеперечисленные проблемы, но для монтирования маршрута по запросу необходимо знать права маршрутизации пользователя, то есть, когда пользователь входит в систему, необходимо знать, какие права маршрутизации есть у текущего пользователя. Таким образом, должно быть, второй вариант больше соответствует хорошему пользовательскому опыту.

项目中的菜单权限控制

  • 1. Мета-атрибуты, связанные с разрешениями

    • noRequireAuth: истинное монтирование напрямую без разрешения
    • manageFree: истинные права управления не отображаются в дереве

  • 2.router.beforeEach() для перехвата маршрутизации

    • Маршруты, не требующие разрешения, освобождаются напрямую. noRequireAuth и manageFree в мета не контролируются разрешениями
    • Перед вводом маршрута запросите отображение меню из бэкенда. Серверная часть оценивает текущие полномочия пользователя в соответствии с токеном и возвращается в соответствующее меню. Интерфейсное рекурсивное сравнение для определения отображаемого окончательного списка меню.

  • 3.router.addRoutes()

    • Динамически добавлять все маршруты, соответствующие разрешениям, через router.addRoutes()

按钮级权限控制(Vue指令v-permission)

  • 1. Каждый модуль имеет четыре разрешения, запрос (получение), добавление (публикация), обновление (помещение), удаление (удаление)
  • 2. Используйте десятичные и двоичные числа для представления разрешений, которыми обладает текущий модуль. 1111(15), взаимосвязь между преобразованным двоичным файлом и разрешением: справа налево (1 означает наличие разрешения, 0 означает отсутствие), первая цифра представляет запрос, вторая цифра представляет добавление, а третья цифра представляет обновление , четвертая цифра означает удаление. Например: двоичный файл 1111 (15), который представляет четыре разрешения для запроса, добавления, обновления и удаления.
    1. Когда будет установлено, что соответствующий модуль не имеет этого разрешения, удалите текущий элемент dom кнопки.

Пример использования:

 <el-button @click="handleClick" v-permission:moduleName.post>新增</el-button>
 <el-button @click="handleClick" v-permission.delete="moduleName">删除</el-button>

3. Контроль доступа к интерфейсу

Наконец, добавьте контроль запросов в качестве последней линии защиты.Может быть неправильно настроена маршрутизация, и кнопка может забыть добавить разрешения.В этом случае контроль запросов может быть использован для получения практических результатов, а неавторизованные запросы будут перехватываться на месте. внешний интерфейс.

  • Внешние и внутренние интерфейсы соглашений используют стиль RESTful, а также соответствуют четырем типам разрешений, включая запрос (получение), добавление (публикация), обновление (помещение) и удаление (удаление). Для операций запроса, как правило, если есть только один параметр, вы должны использовать запрос get.Если есть несколько параметров, вам нужно изменить запрос на публикацию, но вам нужно добавить /query после URL-адреса, чтобы сообщить серверу, что текущий запрос операция используется для и нормального различия запросов добавления (почты). Точно так же, если при удалении пользователя имеется несколько параметров, запрос DELETE также изменяется на запрос POST, а /delete добавляется позже, чтобы отличить его от обычной операции удаления.
Ссылка на ссылку
Категории