JHipster Ролевая маскировка определенных столбцов

Question

В проекте на основе JHipster нам необходимо выборочно отфильтровать определенные столбцы на основе роли/пользователя, входящего в систему. Все пользователи смогут просматривать/изменять большинство столбцов, но только некоторые привилегированные пользователи смогут просматривать/изменять определенные защищенные поля/столбцы.

Похоже, что единственный способ сделать это - использовать EntityListeners. Я могу использовать EntityListener и маскировать определенный столбец во время события PostLoad. Скажем, например, я маскирую столбец my_secure_column с XXX и отображаю его пользователю.

Пользователь затем изменяет некоторые другие поля/столбцы (к которым у него есть доступ) и отправляет форму. Должен ли я снова захватить частично заполненный объект в событии PreUpdate, получить исходное значение для my_secure_column из базы данных и установить его перед сохранением?

Все это кажется неэффективным. Проработал несколько часов, но не смог найти конкретную реализацию, которая наилучшим образом соответствует этому варианту использования.

Редактировать 1: Это выглядит как первый шаг к достижению этого в несколько лучшем виде. Updating Entities with Update Query in Spring Data JPA

Я мог бы использовать определенные частичные обновления, такие как updateAsUserRole, updateAsManagerRole и т. Д., А не постоянно сохранять всю сущность.

@Repository 
public interface CompanyRepository extends JpaRepository<Company, Integer> { 
    @Modifying(clearAutomatically = true) 
    @Query("UPDATE Company c SET c.address = :address WHERE c.id = :companyId") 
    int updateAddress(@Param("companyId") int companyId, @Param("address") String address); 
} 

Answer 1

Безопасность на основе столбцов - непростая задача решить проблему, особенно в сочетании с JPA.

В идеале вам нравится избегать загрузки столбцов, но поскольку вы выбираете объекты, это невозможно по умолчанию, поэтому вам нужно удалить ограниченный контент, переопределив значение после загрузки.

В качестве альтернативы вы можете создать компонент вида (POJO), а затем использовать JPQL Constructor Expression. Лично я бы использовал CriteriaBuilder. construct() вместо конкатенации JPQL-запроса, но тот же принцип.

Что касается обновления данных, пользовательский интерфейс должен приводить к невозможности редактирования ограниченных полей. Однако вам все равно нужно проверить на бэкэнд, и я бы рекомендовал вам проверить, изменился ли столбец, прежде чем вызывать JPA. Как правило, у вас есть изменения в DTO, и в любом случае необходимо будет загрузить Entity, если был изменен ограниченный столбец, вы отправите сообщение об ошибке. Таким образом вы только вызываете JPA после проверки безопасности.