Весна безопасности фильтр цепи URL-адрес соответствия

Question

Я новичок в безопасности весны. Теперь я читаю его документацию. У меня есть вопрос относительно его шаблонов URL фильтра цепи:

Как объяснен в документе:

это можно использовать несколько элементы HTTP для определения различных конфигураций безопасности для различных шаблонов URL. Каждый элемент создает цепочку фильтров внутри внутреннего фильтра FilterChainProxy и шаблон URL, который должен быть сопоставлен с ним. Элементы будут добавлены в том порядке, в котором они объявлены, поэтому сначала должны быть объявлены наиболее конкретные шаблоны.

это также дает пример:

<!-- Stateless RESTful service using Basic authentication --> 
    <http pattern="/restful/**" create-session="stateless"> 
    <intercept-url pattern='/**' access='ROLE_REMOTE' /> 
    <http-basic /> 
    </http> 

, что я не понимаю: URL-адрес шаблона «/ успокоительное/**» уже настроен для HTTP тега, это означает, что все запросы соответствующий этому шаблону будет обрабатываться цепочкой фильтров внутри этого тега http. Однако почему он дает шаблон «match all»: «/ **» для метки intercept-url?

Разве это не дублируется?

Кроме того, если действительно хотите дать еще один образец, не «/ restful/**» лучше? Причина «/ **» будет соответствовать URL-адресам, которые не будут соответствовать «/ restful/**» и, следовательно, не будут обрабатываться этой цепочкой фильтров.

Answer 1

1. Без <intercept-url> теге <http>, это заявление в основном говорит, что любой желающий может получить доступ к любому ресурсу по /restful/** пути. Здесь <intercept-url> ограничивает доступ к пользователям, которым была назначена роль ROLE_REMOTE, что совсем иная.

2. <intercept-url> шаблонов относительно вмещающий шаблон <http> элемента, так что ничего за пределы /restful/** пути будет перехвачены этой декларацией.

Типичная картина является то, что вы будете иметь один <http> элемент с несколькими <intercept-url> элементов, предназначенными для различных моделей URL. Дополнительные элементы <http> могут быть полезны, если вы хотите, чтобы проверка подлинности и управление доступом вела себя по-другому, например управление сеансом или обработчики ошибок проверки подлинности для конечных точек API REST.