Spring Security – security none, filters none, access permitAll – Spring Security – security none, filters none, access permitAll

最后修改: 2013年 5月 22日

中文/混合/英文(键盘快捷键：t)

1. Overview

1.概述

Spring Security provides several mechanisms to configure a request pattern as unsecured or allowing all access. Depending on each of these mechanisms – this can either mean not running the security filter chain on that path at all, or running the filter chain and allowing access.

Spring Security提供了几种机制来配置请求模式为不安全或允许所有访问。根据这些机制的不同，这可能意味着完全不在该路径上运行安全过滤链，或者运行过滤链并允许访问。

2. access=”permitAll”

2.access=”permitAll”

Setting up an <intercept-url> element with access=”permitAll” will configure the authorization so that all requests are allowed on that particular path:

设置一个<intercept-url>元素，并加上access=”permitAll”将配置授权，使所有请求都被允许在该特定路径上。

<intercept-url pattern="/login*" access="permitAll" />

Or, via Java configuration:

或者，通过Java配置。

http.authorizeRequests().antMatchers("/login*").permitAll();

This is achieved without disabling the security filters – these still run, so any Spring Security related functionality will still be available.

这是在没有禁用安全过滤器的情况下实现的–这些过滤器仍在运行，因此任何与Spring Security相关的功能仍可使用。

3. filters=”none”

3.filters=”none”

This is a pre-Spring 3.1 feature that has been deprecated and replaced in Spring 3.1.

这是Spring 3.1之前的功能，在Spring 3.1中已经被淘汰并取代。

The filters attribute disables the Spring Security filters chain entirely on that particular request path:

filters属性在该特定请求路径上完全禁用Spring Security过滤器链。

<intercept-url pattern="/login*" filters="none" />

This may cause problems when the processing of the request will require some functionality of Spring Security.

当请求的处理需要Spring Security的某些功能时，这可能会造成问题。

Since this is a deprecated feature Spring versions newer than 3.0, using it with Spring 3.1 will result in a runtime exception on startup:

由于这是3.0以上版本的Spring的一个废弃功能，在Spring 3.1中使用它将导致启动时出现运行异常。

SEVERE: Context initialization failed
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: 
Configuration problem: The use of "filters='none'" is no longer supported. 
Please define a separate <http> element for the pattern you want to exclude 
and use the attribute "security='none'".
Offending resource: class path resource [webSecurityConfig.xml]
	at o.s.b.f.p.FailFastProblemReporter.error(FailFastProblemReporter.java:68)

4. security=”none”

4.security=”none”

As we saw in the error message above, Spring 3.1 replaces filters=”none” with a new expression – security=”none”.

正如我们在上面的错误信息中看到的，Spring 3.1用一个新的表达式–security=”none”取代了filters=”none”。

The scope has changed as well – this is no longer specified at the <intercept-url> element level. Instead, Spring 3.1 allows multiple <http> elements to be defined – each with its own security filter chain configuration. And so, the new security attribute now belongs on at the <http> element level.

范围也发生了变化–这不再是在<intercept-url>元素级别上指定的。相反，Spring 3.1允许定义多个<http>元素–每个元素都有自己的安全过滤链配置。因此，新的安全属性现在属于<http>元素级别上。

In practice, this will look like:

在实践中，这将看起来像。

<http pattern="/resources/**" security="none"/>

Or with Java configuration:

或者用Java配置。

web.ignoring().antMatchers("/resources/**");

Instead of the old:

而不是旧的。

<intercept-url pattern="/resources/**" filters="none"/>

Similar to filters=”none”, this will also completely disable the Security filter chain for that request path – so when the request is handled in the application, Spring Security features will not be available.

与filters=”none”类似，这也将完全禁用该请求路径的安全过滤器链–因此当该请求在应用程序中被处理时，Spring安全功能将不可用。

This is not a problem for the examples above, which mainly deal with serving static resources – where no actual processing takes place. However, if the request is handled programmatically in some way – then security functionalities such as requires-channel, accessing the current user or calling secured methods will not be available.

这对上面的例子来说不是问题，这些例子主要涉及服务静态资源–没有实际处理。然而，如果请求是以某种方式进行程序化处理的，那么诸如requires-channel、访问当前用户或调用安全方法等安全功能将不可用。

For the same reason, there is no point specifying additional attributes on an <http> element that has already been configured with security=”none” because that request path is unsecured and the attributes will simply be ignored.

出于同样的原因，在已经被配置为<http>元素上指定额外的属性是没有意义的，因为该请求路径是不安全的，这些属性将被忽略。

Alternatively, access=’IS_AUTHENTICATED_ANONYMOUSLY’ can be used to allow anonymous access.

另外，access=’IS_AUTHENTICATED_ANONYMOUSLY’可以被用来允许匿名访问。

5. Caveats for security=”none”

5.security=”none”的注意事项

When using multiple <http> elements, some configured with security=”none”, keep in mind that the order in which these elements are defined is important. We want to have the specific <http> paths first, followed the universal pattern at the very end.

当使用多个<http>元素时，有些元素被配置为security=”none”，请记住，这些元素的定义顺序是很重要的。我们希望先有特定的<http>路径，然后将通用模式放在最后。

Also note that, if an <http> element doesn’t specify a pattern, then by default, that maps to the universal match pattern – “/**” – so again, this element needs to be last. If the order of the elements is not correct, the creation of the security filter chain will fail:

还要注意的是，如果一个<http>元素没有指定模式，那么默认情况下，该元素会映射到通用匹配模式–“/**”–所以同样，这个元素需要放在最后。如果元素的顺序不正确，安全过滤器链的创建将失败。

Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**') 
is defined  before other patterns in the filter chain, causing them to be ignored. 
Please check the ordering in your <security:http> namespace or FilterChainProxy bean configuration
	at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49)
	at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39)

6. Conclusion

6.结论

This article discusses the options of allowing access to a path with Spring Security – focusing on the differences between filters=”none”, security=”none” and access=”permitAll”.

本文讨论了使用Spring Security允许访问路径的选项–重点是filters=”none”、security=”none “和access=”permitAll”之间的区别。

As usual, the examples are available over on GitHub.

像往常一样，这些例子可以在GitHub上找到over。