Опасные опасности использования нитолокальных переменных с EJB3?

Question

Я экспериментирую с решением авторизации и аутентификации, сохраняя класс субъекта на карте Threadlocal. Дизайн предназначен для API, поэтому у меня не будет доступа к вовлеченным сервлетам, и мне нужно использовать EJB3 (поэтому CDI не вариант). У меня есть несколько вопросов об использовании Threadlocal с EJB3

1. Предполагая, что каждый запрос очищает свою нитолокальную карту после его выполнения, есть ли риск использования потоковой переменной с сеансами без сохранения состояния? Другими словами, есть ли какой -либо риск, что два запроса получают доступ к одному и тому же потоку одновременно?

2. Есть ли способ обеспечить соблюдение сервлетов для очистки нитолокала после того, как они закончат? Я изучал перехватчики, но я понял, что они плохо работают с EJB3 и различно работают на разных серверах приложений. Любым другим путем?

Answer 1

Чтобы ответить на мой собственный вопрос, нет, не с какой -либо безопасностью, кажется. Использование потоковой переменной может работать, если у меня есть контроль над всем процессом, но если бы я это сделал, то я мог бы использовать CDI OCH JSP, чтобы сохранить локальные переменные запроса.

Указывает на всех, кто ответил.

Answer 2

Что касается ответа Мартина, стоит отметить, что сама Spring Security в любом случае использует Threadlocal в любом случае по умолчанию (SecurityContextholder), поэтому я бы осторожно использовал его, если вам нужен контекст безопасности, чтобы выжить через вызова EJB. Конечно, это не будет работать через удаленные призывы; Это может с местным, но я не думаю, что есть какие -либо гарантии.

Как правило, при использовании Spring Security я избегаю EJB и использую Spring Framework для подключения среднего уровня POJO и для предоставления таких услуг, как демаркация транзакций через AOP. Затем контекст безопасности доступен по всему среднему уровню, так как поток остается таким же на протяжении всего вызова.

Answer 3

Я бы порекомендовал использовать Threadlocal в контейнере EJB. Авторизация и аутентификация-это перекрестная проблема, я лично смотрю на использование чего-то вроде AOP для этого (например, как это касается весной безопасности).