Pierwszeństwo ograniczenia bezpieczeństwa nad filtrami w serwletach

Analizując ograniczenia bezpieczeństwa i filtry w serwletach, złożyłem następujące deklaracje w pliku web.xml, który nie działał tak, jak oczekiwałem:

<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>

Zgodnie z tym, co przeczytałem: należy napotkać filtryprzed Żądanie osiąga określony adres URL, więc jak to się dzieje, że pierwszeństwo ma ograniczenie bezpieczeństwa?

Wiem, że ma to sens z punktu widzenia bezpieczeństwa (aby dotrzeć do filtra, który chcesz uwierzytelnić), ale chciałbym wiedziećsekwencja wywołana żądaniem.

Czy kontener szuka najpierw zabezpieczonych zasobów, a więc uruchamia ograniczenie bezpieczeństwa?

Ale będzie to sprzeczne z następującym akapitem cytowanym z Head First Servlets and Jsp ”

Pamiętaj, że w DD chodzi o to, co się dziejepo prośba. Innymi słowy, klient złożył już żądanie, gdy Kontener zacznie patrzeć na elementy, aby zdecydować, jak odpowiedzieć. Dane żądania zostały już wysłane przez przewód

lub może żądanie uruchamia zarówno filtr, jak i ograniczenie bezpieczeństwa, ale ograniczenie bezpieczeństwa jest preferowane w stosunku do filtru?

questionAnswers(2)

yourAnswerToTheQuestion