Обертывание провайдера нестандартной аутентификации Spring Security с транзакцией

Question

В моем пользовательском провайдере аутентификации я смог получить объект домена через мой Service API, но когда я сканировал один объект домена на другой, чтобы получить определенное значение для выполнения дополнительных проверок, Spring жалуется, что сеанс Hibernate не существует : -

domain.getAnotherDomain().getProperty(); // epic FAIL

У меня есть следующая транзакция AOP, чтобы обернуть все мои API проекта в транзакцию, и я почти уверен, что мой пользовательский поставщик аутентификации попадает в следующую схему: -

<tx:advice id="txAdvice">
    <tx:attributes>
        <tx:method name="*" propagation="REQUIRED" />
    </tx:attributes>
</tx:advice>

<aop:config>
    <aop:advisor pointcut="execution(* my.project..*.*(..))" advice-ref="txAdvice" />
</aop:config>

У меня также настроен фильтр OpenSessionInView, но я не думаю, что это так или иначе относится к Spring Security.

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

Есть объяснения? Спасибо.

Answer 1

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

Answer 2

Spring жалуется, что сеанс Hibernate не существует

Не совсем уверен, что следую всем вашим вопросам, но я думаю, что приведенное выше утверждение представляет вашу главную проблему, верно? Вы не предоставили никакой трассировки стека, но я предполагаю, что это печально известное «нет сессии или сессия закрыта», типичная для сценария, который вы только что описали:

domain.getAnotherDomain () GetProperty (). // Эпический Сбой

Возможно, я что-то упускаю, но я думаю, что типичный ответ применим и здесь: отобразите ваши отношения с fetch=FetchType.EAGER, чтобы вам не пришлось лениво загружать их, когда сессия уже закрыта.

Answer 3

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

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

Например, retreiveUser из AbstractUserDetailsAuthenticationProvider . Этот метод вызывается из экземпляра (см. Метод authenticate ) и поэтому не может инициализировать транзакцию через механизм прокси AOP. Для получения более подробной информации проверьте @ Транзакционный метод, вызывающий другой метод без аннотации @Transactional?

Модель декларативных транзакций Spring использует прокси AOP. поэтому прокси-сервер AOP отвечает за создание транзакций. Прокси-сервер AOP будет активен, только если методы в экземпляре вызываются извне экземпляра.

Answer 4

Я столкнулся с той же проблемой, и причина была в том, что у меня был фильтр Spring Security, объявленный до фильтра OpenSessionInView в файле web.xml. Как только я обменял их, проблема ушла.

Причина в том, что Spring Security вызывается до открытия сеанса Hibernate с помощью фильтра OpenSessionInView, и поэтому сеанс не был открыт.