Защитный дизайн с пружинами и полосками

Question

Я создаю веб-приложение, используя Stripes и Spring.У него должна быть функция входа в систему / аутентификации.Прямо сейчас я храню информацию о пользователе отдельно от учетных данных пользователя в базе данных.Моя пользовательская модель не содержит учетных данных, поскольку я не хочу передавать ценные пароли.

Spring управляет всеми моими DAO.

Сейчас я внедряю систему безопасности, не основанную на контейнерах.Я сохраняю хэш пароля sha-2 и выполняю сравнение пароля, который был отправлен в форме, с тем, что хранится в базе данных.Это сравнение было протестировано и работает.Я пытаюсь понять, как соединить эту штуку воедино.Прямо сейчас у меня есть LoginActionBean, который перехватывает запросы на вход в систему и использует синглтон "PasswordService", который использует UserDao внутренне для извлечения учетных данных и выполнения сравнения с отправленными параметрами.Моя весенняя фасоль - это:

<bean id="passwordSerivce" class="com.example.store.authentication.PasswordService" factory-method="getInstance">
    <property name="userDAO" ref="userDAO"/>
</bean>

Но тогда синглтону PasswordService требуется:

public void setUserDAO(UserDAO userDAO) { ...}

метод, который на самом деле не имеет смысла в синглтоне (UserDao - это интерфейс).

Я ищу подходящий дизайн.Я читал, что ServiceLocators - это та самая причина, по которой был изобретен Spring.Есть какие-нибудь мысли?

Я также хотел бы знать, как еще я могу это спроектировать.У меня есть ActionBean, который вызывается, когда пользователь нажимает "Войти", но как мне на самом деле пройти аутентификацию?Должен ли я внедрить службу аутентификации в компонент?Создаю ли я синглтон, который может вызвать любой желающий?Есть ли у меня универсальный интерфейс, который использует LoginAcionBean, который вводит Spring?Если бы я не использовал Spring, как бы это было сделано?

Answer 1

1. Я не понимаю, почему нет никакого смысла вводить UserDao.

2. Я не понимаю, почему ваш xml использует factory-method="getInstance";вы можете выбросить все материалы экземпляра и одноэлементные материалы;spring создаст экземпляр одного экземпляра класса password service и внедрит его в любое количество классов, нуждающихся в нем, и все они получат один и тот же экземпляр.Итак, spring создает синглтон для вас.Класс обслуживания паролей может быть простым pojo.Аналогично для реализации UserDao.

Я бы также посоветовал изучить, понять и использовать аннотации spring.По сути, вы используете @Service в классе, который будет внедрен, затем используете @Autowired в установщике в классе, куда он будет внедрен.Вам также нужно добавить что-то в ваш файл конфигурации xml, чтобы включить аннотации.

Answer 2

Добавляя к приведенному выше ответу, просто используйте внедрение конструктора, если вам не нужен установщик для DAO:

<bean id="passwordSerivce" class="...PasswordService">
   <constructor-arg ref="userDAO"/>
</bean>

Если компонент не является классом, которым вы управляете, вам не нужно делать его синглтоном, Spring сделает это по умолчанию.

Лично я не являюсь поклонником аннотаций.

Answer 3

Мое решение состояло в том, чтобы иметь интерфейс с методом "authenticate".Затем создайте класс service, который реализует интерфейс с конструктором, который принимает объект UserDao.Таким образом, объект, которому требуется служба, не выполняет создание экземпляра (это делается spring) и не знает о том, какая базовая реализация выполняется (ldap, единый вход, простое сравнение паролей и т.д.).Кажется , работа выполнена : P