«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.