Spring Security（二十九）：9.4.1 ExceptionTranslationFilter

ExceptionTranslationFilter is a Spring Security filter that has responsibility for detecting any Spring Security exceptions that are thrown. Such exceptions will generally be thrown by an AbstractSecurityInterceptor, which is the main provider of authorization services. We will discuss AbstractSecurityInterceptor in the next section, but for now we just need to know that it produces Java exceptions and knows nothing about HTTP or how to go about authenticating a principal. Instead the ExceptionTranslationFilter offers this service, with specific responsibility for either returning error code 403 (if the principal has been authenticated and therefore simply lacks sufficient access - as per step seven above), or launching an AuthenticationEntryPoint (if the principal has not been authenticated and therefore we need to go commence step three).

ExceptionTranslationFilter是一个Spring Security过滤器，负责检测抛出的任何Spring Security异常。 AbstractSecurityInterceptor通常会抛出此类异常，后者是授权服务的主要提供者。我们将在下一节讨论AbstractSecurityInterceptor，但是现在我们只需要知道它产生Java异常并且对HTTP没有任何了解或者如何对主体进行身份验证。相反，ExceptionTranslationFilter提供此服务，特别负责返回错误代码403（如果主体已经过身份验证，因此根本没有足够的访问权限 - 按照上面的第7步），或者启动AuthenticationEntryPoint（如果主体未经过身份验证，因此我们需要开始第三步）。

9.4.2 AuthenticationEntryPoint

The AuthenticationEntryPoint is responsible for step three in the above list. As you can imagine, each web application will have a default authentication strategy (well, this can be configured like nearly everything else in Spring Security, but let’s keep it simple for now). Each major authentication system will have its own AuthenticationEntryPoint implementation, which typically performs one of the actions described in step 3.

AuthenticationEntryPoint负责上面列表中的第三步。可以想象，每个Web应用程序都有一个默认的身份验证策略（好吧，这可以像Spring Security中的其他几乎一样进行配置，但现在让它保持简单）。每个主要身份验证系统都有自己的AuthenticationEntryPoint实现，该实现通常执行步骤3中描述的操作之一。

9.4.3 Authentication Mechanism

Once your browser submits your authentication credentials (either as an HTTP form post or HTTP header) there needs to be something on the server that "collects" these authentication details. By now we’re at step six in the above list. In Spring Security we have a special name for the function of collecting authentication details from a user agent (usually a web browser), referring to it as the "authentication mechanism". Examples are form-base login and Basic authentication. Once the authentication details have been collected from the user agent, an Authentication "request" object is built and then presented to the AuthenticationManager.

一旦您的浏览器提交您的身份验证凭据（作为HTTP表单帖子或HTTP标头），服务器上就需要“收集”这些身份验证详细信息。到目前为止，我们已经在上面的列表中的第六步了。在Spring Security中，我们有一个特殊的名称，用于从用户代理（通常是Web浏览器）收集身份验证详细信息，并将其称为“身份验证机制”。例如基于表单的登录和基本身份验证。一旦从用户代理收集了身份验证详细信息，就会构建身份验证“请求”对象，然后将其提供给AuthenticationManager。

 

After the authentication mechanism receives back the fully-populated Authentication object, it will deem the request valid, put the Authentication into the SecurityContextHolder, and cause the original request to be retried (step seven above). If, on the other hand, the AuthenticationManager rejected the request, the authentication mechanism will ask the user agent to retry (step two above).

在认证机制收到完全填充的Authentication对象后，它将认为请求有效，将Authentication放入SecurityContextHolder，并使原始请求重试（上面的步骤7）。另一方面，如果AuthenticationManager拒绝了请求，则认证机制将要求用户代理重试（上面的步骤2）。

9.4.4 Storing the SecurityContext between requests

Depending on the type of application, there may need to be a strategy in place to store the security context between user operations. In a typical web application, a user logs in once and is subsequently identified by their session Id. The server caches the principal information for the duration session. In Spring Security, the responsibility for storing the SecurityContext between requests falls to the SecurityContextPersistenceFilter, which by default stores the context as an HttpSessionattribute between HTTP requests. It restores the context to the SecurityContextHolder for each request and, crucially, clears the SecurityContextHolder when the request completes. You shouldn’t interact directly with the HttpSession for security purposes. There is simply no justification for doing so - always use the SecurityContextHolder instead.

根据应用程序的类型，可能需要采用策略来在用户操作之间存储安全上下文。在典型的Web应用程序中，用户登录一次，然后由其会话ID标识。服务器缓存持续时间会话的主体信息。在Spring Security中，在请求之间存储SecurityContext的责任属于SecurityContextPersistenceFilter，它默认将上下文存储为HTTP请求之间的HttpSession属性。它为每个请求恢复SecurityContextHolder的上下文，并且至关重要的是，在请求完成时清除SecurityContextHolder。出于安全目的，您不应直接与HttpSession交互。没有理由这样做 - 总是使用SecurityContextHolder。

 

Many other types of application (for example, a stateless RESTful web service) do not use HTTP sessions and will re-authenticate on every request. However, it is still important that the SecurityContextPersistenceFilter is included in the chain to make sure that the SecurityContextHolder is cleared after each request.

许多其他类型的应用程序（例如，无状态RESTful Web服务）不使用HTTP会话，并将在每个请求上重新进行身份验证。但是，在链中包含SecurityContextPersistenceFilter以确保在每次请求后清除SecurityContextHolder仍然很重要。

 

In an application which receives concurrent requests in a single session, the same SecurityContext instance will be shared between threads. Even though a ThreadLocal is being used, it is the same instance that is retrieved from the HttpSession for each thread. This has implications if you wish to temporarily change the context under which a thread is running. If you just use SecurityContextHolder.getContext(), and call setAuthentication(anAuthentication) on the returned context object, then the Authentication object will change in all concurrent threads which share the same SecurityContext instance. You can customize the behaviour of SecurityContextPersistenceFilter to create a completely new SecurityContext for each request, preventing changes in one thread from affecting another. Alternatively you can create a new instance just at the point where you temporarily change the context. The method SecurityContextHolder.createEmptyContext() always returns a new context instance.

在单个会话中接收并发请求的应用程序中，将在线程之间共享相同的SecurityContext实例。即使正在使用ThreadLocal，它也是从HttpSession为每个线程检索的相同实例。如果您希望临时更改运行线程的上下文，则会产生影响。如果您只使用SecurityContextHolder.getContext（），并在返回的上下文对象上调用setAuthentication（anAuthentication），则Authentication对象将在共享同一SecurityContext实例的所有并发线程中更改。您可以自定义SecurityContextPersistenceFilter的行为，以便为每个请求创建一个全新的SecurityContext，从而防止一个线程中的更改影响另一个线程。或者，您可以在临时更改上下文的位置创建新实例。 SecurityContextHolder.createEmptyContext（）方法始终返回新的上下文实例。