Precedência de restrição de segurança em filtros em Servlets
Ao estudar sobre restrições de segurança e filtros em servlets, fiz as seguintes declarações no arquivo web.xml, que não funcionaram como eu esperava:
<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>
De acordo com o que eu li: filtros devem ser encontradosantes a solicitação atinge um determinado URL, então como a restrição de segurança é invocada primeiro?
Eu sei que faz sentido a partir de uma segurança (para alcançar o filtro você pode ser autenticado), mas eu gostaria de saber osequência desencadeada pelo pedido.
O contêiner pesquisa primeiro os recursos protegidos e, portanto, aciona a restrição de segurança?
Mas isso vai contradizer o seguinte parágrafo citado de Head First Servlets and Jsp "
Lembre-se que no DD, é sobre o que acontecedepois de o pedido. Em outras palavras, o cliente já fez a solicitação quando o Container começa a examinar os elementos para decidir como responder. Os dados da solicitação já foram enviados pelo fio
ou talvez o pedido apenas acione ambos: filtro e restrição de segurança, mas a restrição de segurança é favorecida pelo filtro?