Servlet中过滤器的安全性约束优先级 [英] Precedence of security-constraint over filters in Servlets

问题描述

在研究servlet中的安全性约束和过滤器时，我在web.xml文件中做了以下声明，这些声明无法正常工作：

While studying about security-constraints and filters in servlets, I made the following declarations in the web.xml file, which didn't work as I expected:

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

根据我读到的内容：在请求到达之前应该遇到过滤器某个网址，那么，为什么首先调用安全约束呢？

According to what I read: filters should be encountered before the request reaches a certain url, so, how come the security-constraint is invoked first ?

我知道从安全方面来说这是有道理的（到达过滤器，你需要进行身份验证） ），但我想知道请求触发的序列。

I know that it makes sense from a security wise (to reach the filter you mush be authenticated), but I'd like to know the sequence triggered by the request.

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

Does the container searches first for the secured resources thus it triggers the security-constraint?

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

But this will contradict with the following paragraph quoted from Head First Servlets and Jsp "

请记住，在DD中，关于
在请求后发生了什么。换句话说，客户已经在
请求了Container开始查看
元素以决定如何响应。请求
数据已经通过网络发送

Remember that in the DD, the is about what happens after the request. In other words, the client has already made the request when the Container starts looking at the elements to decide how to respond. The request data has already been sent over the wire

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

or maybe the request just triggers both: filter and security-constraint, but the security-constraint is favored over the filter ?

推荐答案

容器首先处理安全约束。

The container processes the security constraints first.

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

In a nutshell the Servlet container first examines the incoming URL and checks if it matched the so-called excluded or unchecked constraints. Excluded means the URL can not be accessed by anyone, while unchecked means the opposite and allows everyone to access the URL.

在此阶段，容器可以调用您自己的代码你安装了一个所谓的JACC提供商。

At this stage the container can call your own code if you installed a so-called JACC provider.

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

After this the container may try to authenticate the current user, where it can call your own code again. If you registered a SAM (ServerAuthModule) this will always be called at this point, if you didn't register a SAM or when you are working with a non-full Java EE implementation (e.g. a Java EE web profile server like TomEE or a bare Servlet container like Tomcat) it depends on the server if some kind of server specific login module is always called (rare) or only called when access is not granted to the unauthenticated user (typical).

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

The SAM is a filter-like thing as it can redirect, forward and wrap the request and response, but it's not an HTTP Servlet Filter.

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

After authentication succeeds your JACC Policy will be called again, or when you haven't installed one the container will use a proprietary mechanism to see if you now have access when authenticated.

如果确实有权访问，则会调用所谓的资源，这意味着容器将调用过滤中的第一个Filter chain，最终将调用请求URL映射到的目标Servlet。

If it's indeed determined that you have access, the so-called "resource" will be invoked, which means the container will call the first Filter in the filtering chain, which will eventually call through to the target Servlet to which the requested URL was mapped.

您可以在此处阅读有关SAM的更多信息： http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication。 html

You can read more about the SAM here: http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html

此处有关JACC提供商的更多信息： http://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html

And more about JACC providers here: http://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html

这篇关于Servlet中过滤器的安全性约束优先级的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！