Question

在研究servlet中的安全性约束和过滤器时，我在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之前，应该遇到过滤器，那么，为什么首先调用security-constraint呢？

我知道从安全方面来说这是有意义的（到达要验证的过滤器），但我想知道请求触发的序列。

容器首先搜索安全资源，从而触发安全约束吗？

但这与Head First Servlets和Jsp引用的以下段落相矛盾“

请记住，在DD中，关于什么在请求之后发生。换句话说，客户已经做了当Container开始查看时的请求决定如何回应的要素。请求数据已经通过电汇发送

或者请求可能只触发两个：filter和security-constraint，但是安全约束比过滤器更受青睐？

Answer 1

容器首先处理安全约束。

简而言之，Servlet容器首先检查传入的URL并检查它是否与所谓的排除的或未检查的约束相匹配。被排除意味着任何人都无法访问该URL，而未选中则意味着相反，并允许每个人访问该URL。

在此阶段，如果安装了所谓的JACC提供程序，容器可以调用您自己的代码。

在此之后，容器可能会尝试验证当前用户，在那里它可以再次调用您自己的代码。如果您注册了SAM（ServerAuthModule），那么此时将始终调用此方法，如果您未注册SAM或使用非完整Java EE实现（例如Java EE Web配置文件服务器） TomEE或像Tomcat这样的裸Servlet容器它取决于服务器是否始终调用某种特定于服务器的登录模块（罕见）或仅在未授权用户（典型）未授予访问权限时调用。

SAM是类似过滤器的东西，因为它可以重定向，转发和包装请求和响应，但它不是HTTP Servlet过滤器。

验证成功后，将再次调用您的JACC策略，或者当您尚未安装JACC策略时，容器将使用专有机制查看您是否在验证时具有访问权限。

如果确实有权访问，那么将调用所谓的“资源”，这意味着容器将调用过滤链中的第一个Filter，最终将调用请求到的目标Servlet 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

Answer 2

过滤器执行进入＆＃34;服务＆＃34;请求的一面。安全约束在此之前运行。它们帮助服务器决定是否提供URL。您可以将过滤器角色视为在servlet执行之前/之后执行的事情＆＃34;。

Servlet中过滤器的安全性约束优先级

2 个答案: