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