На мой взгляд, разрешения относятся к тому, может ли пользователь получить доступ к определенному интерфейсу. В соответствии с интерфейсом, даже если пользователь обращается к странице, которую он не должен видеть, у него нет разрешения на доступ к интерфейсу, поэтому, даже если он входит на страницу, он не может видеть соответствующие данные. Но что нам нужно сделать во внешнем интерфейсе, так это позволить пользователю напрямую получать подсказку при доступе к этой странице без разрешения.
Но сейчас маршрутизацией страниц во многих проектах управляет фронтенд.Как это сделать?Далее я поделюсь решениями, которые использовал в прошлых проектах.
Я написал демо и загрузил его на github по следующему адресу:admin-permission-demo
Как разработать таблицу базы данных
В начале, когда я подключился к серверной части, чтобы удовлетворить этот спрос, я был очень растерян и чувствовал, что у меня нет возможности начать. Потому что я вообще не знаю, как осуществляется контроль разрешений, и я не знаю, что разрешения на самом деле ограничивают доступ пользователей к интерфейсу. Итак, прежде чем я начну, я думаю, необходимо рассказать о том, как устроена таблица разрешений. В нашем проекте мы используемRBAC, на самом деле очень просто, есть три вещи: пользователи, роли, разрешения (ресурсы). Я слишком ленив, чтобы рисовать картинки, поэтому я могу просто использовать картинку, нарисованную кем-то другим, чтобы избежать проблем.
Это разрешение является интерфейсом в проекте, и смысл очевиден. Роли указываются, к каким интерфейсам можно получить доступ, а затем роли назначаются пользователям. Таким образом, вы можете контролировать, к каким интерфейсам пользователь имеет доступ, а к каким нет.
Разрешения меню и разрешения кнопок
Примерный вид таблицы разрешений в нашем проекте:
| id | p_id | type | permission | name |
|---|---|---|---|---|
| идентификатор первичного ключа | идентификатор родителя | Тип: меню или кнопка | Идентификатор органа | имя |
Разрешения делятся на разрешения меню и разрешения кнопок.Что вы имеете в виду?
Например, сейчас мы собираемся разработать страницу под названием управление пользователями, На этой странице управления пользователями мы будем выполнять некоторые операции по добавлению, удалению, проверке и изменению пользователей. Я называю это управлением пользователямиразрешения меню, операция добавления, удаления, проверки и модификации (интерфейса) под ним называетсякнопки разрешений. P_id этих интерфейсов, очевидно, является идентификатором первичного ключа разрешения меню.
[
{
p_id: '',
id: 1000,
name: '权限管理',
type: 1, // 菜单
permission: 'permission_manage',
children: [
{
p_id: 1000,
id: 1100,
name: '用户管理',
type: 1, // 菜单
permission: 'user_manage',
children: [
{
p_id: 110,
id: 1101,
name: '添加用户',
type: 2, // 按钮
}
...
]
}
]
}
]
Как насчет того, очень знакома эта структура данных, это просто левое меню в системе управления. эторазрешения меню, что использует внешний интерфейс при управлении доступом к странице. Эта структура данных просто написана мной для удобства понимания. В моем проекте данные разрешений, которые я запрашивал у бэкенда, выглядят не так, это массив, каждый элемент — это данные, и не выполняется операция группировки (то есть нет потомков). Таким образом, после того, как внешний интерфейс получит данные, его можноtypeинтегрироваться вразрешения менюсбор икнопки разрешенийСбор, который удобен для последующего использования.
Интерфейсный код для реализации контроля разрешений
Поняв, как устроены разрешения, давайте поговорим о том, как реализован интерфейсный код.
Все мои прошлые проекты использовали react + antd + dva + typescript. По сути, неважно, какая технология используется во фронтенде, важно, чтобы идеи были поняты, а остальное — лишь разница в реализации кода.
Во-первых, я попрошу серверную часть предоставить мне интерфейс для запроса всех разрешений текущего пользователя. Тогда я бы разделил его наразрешения менюа такжекнопки разрешенийиспользоватьreduxсправляться.
Рендеринг левого меню
Первый — отрисовать левое меню. В обычных условиях в проекте будет специальный конфигурационный файл для левого меню, в котором определяются имя, иконка, путь к странице и другая информация меню. Некоторые страницы меню требуют управления разрешениями, а другие нет. Для страниц, которые должны управляться разрешениями, я добавлю поле под названием «Идентификатор меню».
interface MenuDataItem {
name: string; // 菜单名字
icon?: string;
path: string;
children?: Array<MenuDataItem>;
permission?: string; // 菜单标识
}
const menuData: MenuDataItem[] = [...];
Левое меню в проекте будет основано на этомmenuDataотображается. Логика здесь заключается в том, чтобы сначала посмотреть, есть ли в меню логотип меню, а если нет, отобразить его напрямую. Если есть логотип меню, это зависит от того, есть ли у пользователя это разрешение меню, и он будет отображаться, если есть, иначе он не будет отображаться. Структура каждого проекта определенно отличается, поэтому больше кода выкладывать не буду.Важна идея.Для конкретной реализации я написал демо и выложил на github.Если интересно,можете посмотреть , Это адрес:admin-permission-demo.
Контроль уровня маршрутизации
Однозначно управлять только рендерингом левого меню недостаточно, им нужно управлять на уровне роутинга. При нормальных обстоятельствах в проекте будет таблица маршрутизации,reactЕсли маршрут также является компонентом, вы можете управлять им в том месте, где маршрут отображается.vueглобальная конфигурацияrouterДа, вохранник маршрутаПросто ограничьте. Точно так же страница соответствует маршруту меню, чтобы увидеть, есть ли у пользователя разрешение меню, если нет, странице будет предложено, что разрешения недостаточно, и страница будет отображаться нормально.
Элементы управления на уровне кнопок
Возьмем, к примеру, управление пользователями: добавление, удаление, проверка и изменение. Возможно, у пользователя есть разрешение только на удаление, проверку и изменение, но не разрешение на добавление. В это время кнопка "Добавить пользователя" не должна отображаться на странице, иначе данные о пользователе введены давно, и будет неловко отправить запрос на бэкенд и проверить недостаточность разрешения. Я не могу сделать эту операцию, а ты еще показываешь Что ты делаешь для меня?
В это время написать компонент, не важно как он называется, например он называетсяPermissionButtonПучок. В случае react исходная кнопка передается в компонент как потомки, а в случае vue она должна быть<slot>. Затем компонент также получаетprops, это массив, просто позвоните емуpermissionsПучок. Каждый элемент массива является идентификатором разрешения кнопки, который представляет, какие разрешения необходимы для отображения кнопки, или может иметь одно из них для отображения. в обеспеченииpropsДля управления дескриптором значение равно каждому или некоторым. Every означает, что можно отобразить все, а some означает, что можно отобразить одно.
Затем нужно проверить пользователякнопки разрешений. Если у вас есть измененный компонент, вы можете отобразить исходный компонент, если у вас его нет, просто не отображайте его.
Суммировать
Это небольшая практика, которую я накопил в системе фонового управления. Если у вас есть лучшее решение или вы считаете, что есть возможности для улучшения, добро пожаловать на общение.
Это может быть не очень удобно для пользователей Vue. Поскольку демо реализовано с помощью реакции. Но я не думаю, что это решение сильно отличается от реакции и vue. Если позже у меня будет возможность использовать vue на работе, я воспользуюсь демо-версией vue в обновленной версии. Самое главное — понять это разрешение, что на самом деле несложно. Надеюсь помочь нуждающимся.
Конкретная реализация — это точно не несколько строчек кода, которые можно четко разместить, и то, как реализуется код, тоже связано с конкретной структурой проекта.
Я предоставил демо и загрузил его на github по следующему адресу:admin-permission-demo.
Демонстрация также основана на моем собственном шаблоне системы управления, адрес:antd-admin