Защита и снятие защиты данных из приложения в БД

В моем веб-приложении на основе spring-maven-jpa некоторые данные должны быть зашифрованы непосредственно перед сохранением в БД, а затем расшифрованы обратно при объединении из БД.

Итак, я создал свой сервис шифрования, и теперь мне интересно, какой должна быть лучшая реализация.

С точки зрения OO, я думаю, что каждая сущность должна знать, как защищать и не защищать себя. Это приводит меня к внедрению моего шифровальщика в абстрактный базовый объект:

public abstract class BaseEntity {

    @Autowired(required = true)
    protected SecurityProvider securityService;

    public BaseEntity() {
    }

    /**
     * secure the entity (if required) using the securityService
     */
    @PrePersist
    @PreUpdate
    protected abstract void secure();

    /**
     * un-secure the entity (if required) using the securityService
     */
    @PostLoad
    protected abstract void unsecure();

    /*--- Getters & Setters ---*/

    public SecurityProvider getSecurityService() {
    return securityService;
    }

    public void setSecurityService(SecurityProvider securityService) {
    this.securityService = securityService;
    }
} 

Как видите, для этого я пытаюсь использовать обратные вызовы @PrePersist, @PreUpdate и @PostLoad.

На данный момент у меня есть некоторые проблемы с инъекцией шифровальщика, поэтому я не могу проверить его полностью.

Вопрос в том, выглядит ли это хорошей практикой? Можете ли вы предложить улучшения или лучший способ?

ОБНОВИТЬ:

После выполнения некоторых тестов кажется, что аннотации @PrePersist и @PreUpdate работают нормально, и каждый объект шифруется непосредственно перед записью в БД. Но @PostLoad, похоже, работает не так, как я ожидал. Я думал, что он будет запускаться каждый раз, когда я закончу объединение объекта из БД, но по какой-то причине метод не вызывается. Я неправильно понял идею @PostLoad?


person forhas    schedule 02.12.2012    source источник


Ответы (1)


Для этого хорошо подходит шаблон проектирования «Команда». В основном у вас будет класс под названием «SecurityClass» с методами шифрования и дешифрования.

Он принимает параметр типа «сущность» и выполняет для них некоторый тип шифрования. Преимущество использования шаблона проектирования Command заключается в том, что любой объект типа Entity может быть зашифрован, и нет необходимости в наследовании!

Тем не менее, использование наследования для того, чтобы сделать методы частью класса Entity, — это нормально, но в соответствии с концепцией «дизайна, основанного на ответственности», является ли работа сущности заключаться в шифровании самой себя или это больше работа какого-то внешнего агента? ?

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

person christopher    schedule 02.12.2012
comment
Спасибо, Крис. Я понимаю, к чему вы клоните, но я думаю, что буду придерживаться текущего подхода. Я согласен, что здесь нет однозначного ответа. Моя текущая проблема связана с JPA, хотя я не могу разблокировать объекты с помощью аннотации @PostLoad. К сожалению, мой незащищенный метод не вызывается. - person forhas; 02.12.2012
comment
Вы пробовали отлаживать свой код? Может быть, пройти через это. Или вы можете просто поместить эхо куда-нибудь. Просто чтобы дать вам представление о том, что происходит внутри вашего кода. - person christopher; 02.12.2012
comment
Что ж, эти аннотации на самом деле запускают некоторый код в стиле JPA AOP, а не мой. Мне просто интересно, правильно ли это использование этих аннотаций. - person forhas; 02.12.2012
comment
Я не эксперт по JPA AOP, но я уверен, что аннотация @PostLoad работает только с конфигурацией диспетчера сущностей. Вы пробовали это? - person christopher; 03.12.2012