У меня есть веб-приложение, которое использует безопасность Spring. Он использует элементы
для описания фильтров доступа для разных URL-адресов. По умолчанию при этом не учитываются параметры запроса URL. Мне нужно было установить собственные правила безопасности URL-адреса на основе параметров запроса. Итак, я сделал следующее:
1) Я создал класс постпроцессора bean, который включит параметр параметров запроса для механизмов безопасности Spring:
<beans:beans>
. . .
<beans:bean class="MySecurityBeanPostProcessor">
<beans:property name="stripQueryStringFromUrls" value="false" />
</beans:bean>
. . .
</beans:beans>
И код:
public class MySecurityBeanPostProcessor implements BeanPostProcessor {
private Boolean stripQueryStringFromUrls = null;
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if (bean instanceof DefaultFilterInvocationSecurityMetadataSource && stripQueryStringFromUrls != null) {
((DefaultFilterInvocationSecurityMetadataSource) bean)
.setStripQueryStringFromUrls(stripQueryStringFromUrls.booleanValue());
}
return bean;
}
// code stripped for clarity
}
Это должно установить метаданные безопасности Spring источник для учета параметров запроса. Я отладил приведенный выше код, и устанавливается свойство stripQueryStringFromUrls
.
2) В моем контексте безопасности xml у меня есть следующие определения:
<intercept-url pattern="/myUrl?param=value" access="!isAuthenticated() or hasRole('ROLE_GUEST')" />
<intercept-url pattern="/myUrl" filters="none" />
...
<intercept-url pattern="/**" access="isAuthenticated()" />
Как видите, мне нужно получить доступ к URL-адресу с указанными параметрами, только если пользователь не аутентифицирован или использует гостевую учетную запись. Кроме того, я добавил правило для того же URL-адреса, но без каких-либо параметров, в котором нет фильтров.
Насколько мне известно, весенняя безопасность должна быть настроена с указанием более конкретного URL ПЕРЕД менее конкретным, потому что в противном случае цепочка сначала обнаружит более общее правило и не перейдет к более конкретно. Вот почему я ожидаю, что URL-адрес с параметрами будет более конкретным, поэтому будет отказано в доступе аутентифицированным пользователям, не являющимся гостями. Вместо этого применяется определенное ниже более общее правило. Вот результат:
INFO [STDOUT] 186879 [http-0.0.0.0-8080-1] DEBUG org.springframework.security.web.FilterChainProxy - кандидат: '/ myUrl'; шаблон - / myUrl; matched = true
ИНФОРМАЦИЯ [STDOUT] 186879 [http-0.0.0.0-8080-1] DEBUG org.springframework.security.web.FilterChainProxy - / myUrl? param = value имеет пустой список фильтров
Я также пробовал чтобы удалить правило для URL без параметров. Затем вместо того, чтобы заставить работать мое правило для URL-адреса с параметрами, фильтр выбирает шаблон / **
и требует, чтобы пользователи вошли в систему.
Вывод для этого:
ИНФОРМАЦИЯ [СТАНДАРТНЫЙ ВЫХОД] 73066 [http-0.0.0.0-8080-1] ОТЛАДКА org.springframework.security.web.FilterChainProxy - кандидат: '/ myUrl'; шаблон - / **; matched = true
ИНФОРМАЦИЯ [STDOUT] 73068 [http-0.0.0.0-8080-1] ОТЛАДКА org.springframework.security.web.FilterChainProxy - / myUrl? Param = значение в позиции 1 из 8 в дополнительной цепочке фильтров; Фильтр запуска: 'SecurityContextPersistenceFilter'
Приложение написано на Java 1.6, использует Spring v3.0 и развернуто на JBoss v5.1.0-GA на Linux-машине. Я не понимаю, почему фильтры ведут себя так, как я описал. Будем очень признательны за вашу помощь и советы.
Edit:
В заключение я заметил, что фильтр / myUrl? Param = value
никогда не применяется - как если бы запись в security-context.xml была проигнорирована. Это соответствует тому поведению, которое я наблюдал до сих пор. Я также попытался заменить filters = "none"
на access = "allowAll"
, переключился на регулярное выражение (и соответственно изменил шаблоны - например, / myUrl? Param = value
становится \ A / myUrl \? Param = value \ Z
), и во всех вариантах поведение, которое я получаю, одинаковое.
Редактировать 2:
Проблема, описанная здесь, на самом деле недопустима. Причины этого заключаются в следующем: проект, в котором присутствует проблема, исключил некоторые пакеты Spring из-за внутренних конфликтов библиотек и несовместимости, в то время как вся установка каким-то образом работала. Я никогда не знал об этом, и на самом деле эта неочищенная конфигурация делает весь вопрос устаревшим. Конкретная причина в том, что реализации методов isAuthenticated () и isAnonymous () не работали должным образом, поэтому любые советы, представленные здесь, не работали.