1. Обзор
JHipster поставляется с двумя ролями по умолчанию — ПОЛЬЗОВАТЕЛЬ и АДМИНИСТР — но иногда нам нужно добавить свои собственные.
В этом руководстве мы создадим новую роль с именем МЕНЕДЖЕР, которую мы сможем использовать для предоставления дополнительных привилегий пользователю.
Обратите внимание, что JHipster использует термин « власти
» как взаимозаменяемый с ролями
. В любом случае, мы по сути имеем в виду одно и то же.
2. Изменения кода
Первым шагом для создания новой роли является обновление класса AuthoritiesConstants
. Этот файл создается автоматически, когда мы создаем новое приложение JHipster, и содержит константы для всех ролей и полномочий в приложении.
Чтобы создать нашу новую роль MANAGER, мы просто добавляем новую константу в этот файл:
public static final String MANAGER = "ROLE_MANAGER";
3. Изменения схемы
Следующим шагом является определение новой роли в нашем хранилище данных.
JHipster поддерживает множество постоянных хранилищ данных и создает задачу первоначальной настройки, которая заполняет хранилище данных пользователями и полномочиями.
Чтобы добавить новую роль в настройку базы данных, мы должны отредактировать файл InitialSetupMigration.java
. У него уже есть метод addAuthorities
, и мы просто добавляем нашу новую роль в существующий код:
public void addAuthorities(MongoTemplate mongoTemplate) {
// Add these lines after the existing, auto-generated code
Authority managerAuthority = new Authority();
managerAuthority.setName(AuthoritiesConstants.MANAGER);
mongoTemplate.save(managerAuthority);
}
В этом примере используется MongoDB, но шаги очень похожи на другие постоянные хранилища, которые поддерживает JHipster.
Обратите внимание, что некоторые хранилища данных, такие как H2, полагаются исключительно на файл с именем author.csv
и поэтому не содержат сгенерированного кода, требующего обновления.
4. Использование нашей новой роли
Теперь, когда мы определили новую роль, давайте посмотрим, как использовать ее в нашем коде.
4.1. Java-код
На бэкэнде есть два основных способа проверить, есть ли у пользователя полномочия на выполнение операции.
Во- первых, мы можем изменить SecurityConfiguration
, если хотим ограничить доступ к определенному API:
public void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/management/**").hasAuthority(AuthoritiesConstants.MANAGER);
}
Во- вторых, мы можем использовать SecurityUtils
в любом месте нашего приложения , чтобы проверить, находится ли пользователь в роли:
if (SecurityUtils.isCurrentUserInRole(AuthoritiesConstants.MANAGER)) {
// perform some logic that is applicable to manager role
}
4.2. Внешний интерфейс
JHipster предоставляет два способа проверки ролей во внешнем интерфейсе. Обратите внимание, что в этих примерах используется Angular, но аналогичные конструкции существуют и для React.
Во- первых, любой элемент шаблона может использовать директиву *jhiHasAnyAuthority
. Он принимает одну строку или массив строк:
<div *jhiHasAnyAuthority="'ROLE_MANAGER'">
<!-- manager related code here -->
</div>
Во- вторых, класс Principal
может проверить , есть ли у пользователя определенная роль:
isManager() {
return this.principal.identity()
.then(account => this.principal.hasAnyAuthority(['ROLE_MANAGER']));
}
5. Вывод
В этой статье мы увидели, как просто создавать новые роли и полномочия в JHipster. Хотя роли ПОЛЬЗОВАТЕЛЯ и АДМИНИСТРАТОРА по умолчанию являются отличной отправной точкой для большинства приложений, дополнительные роли обеспечивают большую гибкость.
С дополнительными ролями у нас есть больший контроль над тем, какие пользователи могут получить доступ к API и какие данные они могут видеть во внешнем интерфейсе.
Как всегда, код доступен на GitHub .