Фронтенд на самом деле сложно иметь проверку разрешений, потому что с точки зрения безопасности фронтенд не является абсолютно безопасным, и злоумышленники всегда могут модифицировать код фронтенда. Разрешения для API могут быть гарантированы сервером, но разрешения для страниц могут быть более проблематичными. Лучший способ, конечно, бэкэнд-контроль, то есть бэкэнд NodeJs. Если этот уровень безопасности не может быть достигнут (но не является обязательным для многих приложений), остальные методы не сильно отличаются, но если вам нужно поддерживать динамическую настройку, вам нужна маршрутизация на стороне сервера.
Маршрутизация разрешений Antd Pro
Эта часть является кодом шаблона Antd Pro, потому что React Router и umi не инкапсулируют поток разрешений (рабочий процесс) (хотя это очень просто реализовать). umi можно добавить в конфигурациюRoutesполе для ввода компонента аутентификации, Antd Pro'sRoutesс помощью самостоятельно реализованныхAuthorizedкомпоненты.
Antd Pro добавляет еще одинauthorityполе, используемое для определения полномочий каждого маршрута. Команда Antd Pro должна быть готова сделать это очень гибким, потому что вcheckPermissionsобещания здесь приемлемы, но вsrc/pages/Authorizedнаконец увиделgetRouteAuthorityОпределение ts принимает толькоstringа такжеstring[].这也是有原因的，我猜测是 umi 对配置里的 routeDataДелать сериализацию, что приводит к потере функции. Если вам нужно написать собственный метод аутентификации маршрутизации, вам, возможно, придется начать с этого места.
Компонент разрешений Antd Pro находится вsrc/components/Authorizedпод модуль. По умолчанию этот модуль экспортируетRenderAuthorizeфункции высшего порядка от , принимающиеAuthorizedкомпоненты иcurrentAuthorityкак параметр. Роль этой функции более высокого порядка основана на входящемcurrentAuthorityдля разбора (разбора) разрешений текущего пользователя, который внутренне используетCURRENTПеременные используются для кэширования результатов синтаксического анализа и предоставления их внешнему использованию модуля, чтобы избежать потери эффективности, вызванной повторным синтаксическим анализом.
Мы также можем не использовать эту высокоуровневую функцию, чтобы метод получения входящего разрешения вызывался каждый раз (в Antd Pro этоgetAuthority).
Я чувствую, что здесь есть небольшая путаница, это окончательная конфигурация.getAuthorityизAuthorizedпомещатьutilsвнутри. Я думаю, что экземпляр конфигурации по умолчанию лучше положить в исходную папку компонента, и это более организовано.
Последний взгляд наPagesфактически используется вAuthorizedкомпоненты. Видим его тип интерфейса TypeScript (другими словами, с TypeScript действительно удобно смотреть на исходный код):
type IAuthorizedType = React.FunctionComponent<AuthorizedProps> & {
Secured: typeof Secured;
check: typeof check;
AuthorizedRoute: typeof AuthorizedRoute;
};
Содержание этого компонента очень простое, то есть вызовcheckдля проверки разрешений. этоcheckабстрагируетсяcheckPermissionsПовторная инкапсуляция метода по существу заключается в реализации функции частичного приложения, которая упаковывает текущее разрешение. Как упоминалось ранее,checkPermissionsдля различных типовauthorityЧто касается поддержки (например, функций), конкретные детали относительно просты и не будут подробно описаны.
В конце концов, это то, что мыsrc/pages/AuthorizedПакеты, замеченные в:
<Authorized
authority={getRouteAuthority(location.pathname, routes) || ''}
noMatch={isLogin ? <Redirect to="/exception/403" /> : <Redirect to="/user/login" />}>
{children}
</Authorized>
Вся логика суждения реализована в одной записи.
Первоначальное намерение исследования компонентов разрешений Antd Pro заключалось в основном в некоторых особых потребностях и случайных ошибках посередине. Например, в начале я столкнулся с ошибкой, которая перенаправляла на страницу входа после входа в систему. Проанализировав исходный код, я обнаружил, что основная причина заключалась в том, чтоCURRENTПеременная кэширует разрешения, когда вы не вошли в систему. Решение тоже очень простое, просто позвонитеreloadAuthorizedВот и все. На самом деле, это также упоминается в документации, но это соглашение не очень четко предлагается, поэтому я думал, что Antd Pro сделает этот шаг неявно, но я слишком много думал.
Также, когда я устанавливаю маршрут в конфигурации, для иRoutesтот же уровеньauthorityКонфигурация недействительна. Однако это относится к логике настройки чтения umi:
{
path: '/',
component: '../layouts/BasicLayout',
Routes: ['src/pages/Authorized'],
authority: ['admin', 'user'],
routes: [
// forms
{
path: '/form',
icon: 'form',
name: 'form'
},
],
}
Короче говоря, Antd Pro просто инкапсулирует логику оценки разрешений, чтобы компенсировать недостатки React Router.
Переопределить хранилище разрешений Antd Pro
Antd Pro хранит все разрешения на переднем конце по умолчанию (разрешения страницы и разрешения пользователя). Antd Pro использовался для резкой маршрутизациислужба поддержки, который представляет собой режим плагина, который изменяет функцию рендеринга приложения. Но потом эту часть убрали, потому что ее данные основаны на mock, и общий сервер сообщит об ошибке, если она не будет реализована.
api/auth_routes Это серьезно повлияло на выпуск
Эта часть процесса была обнаружена мной археологически... На самом деле, я думаю, что это хорошо, но, возможно, это влияние сообщества на проекты с открытым исходным кодом...
При аутентификации на основе токенов мы можем извлечь текущую идентификационную информацию из токена jwt (обратите внимание, что это небезопасно), но это не обязательно. Мы можем получить внутренний маршрут напрямую на основе токена текущего пользователя. Насколько я понимаю бэкенд роутинг, фронтенд по прежнему будет иметь конфигурацию в config.ts, т.к. такие компоненты как компоненты не могут управляться на бэкенде.
В сообществе есть много людей, которые хотят достичьпосле входаСпособ получения маршрутизации, который в основном основан на маршрутизации на основе ролей, относительно прост. Такое ощущение, что это отражение незрелости Antd Pro.
В настоящее время метод маршрутизации асинхронного монтирования, предоставляемый umi, решается с помощью механизма подключаемых модулей, который не кажется слишком формальным (доступным). И это в app.js и не может быть обработано после входа в систему.
Наконец, моя собственная реализация заключается в том, чтобы монтировать маршрут после асинхронного запроса на вход в систему, но это возможно только черезg_routesРабота с глобальными переменными выглядит не очень формально, и мы можем только ожидать, что команда umi приложит настойчивые усилия.