Старшинства безопасности-ограничение через фильтры в сервлетах

Question

Учась о безопасности-ограничениях и фильтрах в сервлетах, я сделал следующие объявления в файле web.xml, который не работает, как я ожидал:

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>BeerSelector</web-resource-name> 
     <url-pattern>/SelectBeer.do</url-pattern> 
     <http-method>GET</http-method> 
     <http-method>POST</http-method> 
     </web-resource-collection> 
    <auth-constraint> 
     <role-name>Admin</role-name> 
    </auth-constraint> 
</security-constraint> 


    <filter> 
    <filter-name>LoginFilter</filter-name> 
    <filter-class>model.MyFilter</filter-class> 
    </filter> 


    <filter-mapping> 
    <filter-name>LoginFilter</filter-name> 
    <url-pattern>/SelectBeer.do</url-pattern> 
    </filter-mapping> 

В соответствии с тем, что я читал: фильтры должны встречаться до, запрос достигает определенного URL-адреса, поэтому, как же происходит принудительное ограничение безопасности?

Я знаю, что это имеет смысл с точки зрения безопасности (чтобы получить фильтр, который вы пропустили, но я хотел бы знать последовательность , вызванную запросом.

Выполняет ли контейнер сначала поиск защищенных ресурсов, тем самым он вызывает ограничение безопасности?

Но это противоречит следующему пункту цитированном Head First сервлетов и Jsp "

Помните, что в DD, то есть о том, что происходит после запроса. Другими словами, клиент уже сделал запрос, когда контейнер начинает смотреть на элементах, чтобы решить, как реагировать. данные запроса уже отправлены по проводам

или, возможно, запрос просто запускает оба параметра: фильтр и ограничение безопасности, но ограничение безопасности предпочтительнее фильтра?

Answer 1

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

Answer 2

Контейнер сначала обрабатывает ограничения безопасности.

В двух словах контейнер сервлет первым анализирует входящий URL и проверяет, если оно соответствует так называемым исключены или непроверенных ограничений. Исключено означает, что URL-адрес не может быть доступен никому, в то время как unchecked означает противоположное и позволяет каждому получить доступ к URL-адресу.

На этом этапе контейнер может вызывать ваш собственный код, если вы установили так называемый поставщик JACC.

После этого контейнер может попытаться аутентифицировать текущего пользователя, где он может снова позвонить вашему собственному коду. Если вы зарегистрировали SAM (ServerAuthModule), это всегда будет вызываться в этот момент, если вы не зарегистрировали SAM или когда работаете с нереализованной реализацией Java EE (например, сервер веб-профиля Java EE, такой как TomEE или пустой контейнер сервлетов, такой как Tomcat) зависит от сервера, если какой-либо серверный модуль входа в систему всегда называется (редко) или вызван только тогда, когда доступ не предоставляется неавторизованному пользователю (типичный).

SAM - это подобная фильтру вещь, поскольку она может перенаправлять, пересылать и обертывать запрос и ответ, но это не фильтр сервлетов HTTP.

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

Если действительно определено, что у вас есть доступ, вызывается так называемый «ресурс», что означает, что контейнер вызовет первый фильтр в цепочке фильтрации, который в конечном итоге вызовет целевой сервлет, к которому запрошенный URL был сопоставлен.

Вы можете прочитать больше о SAM здесь: http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html

И еще о поставщиках JACC здесь: http://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html