mirror of
https://github.com/spring-projects/spring-security.git
synced 2025-05-31 01:02:14 +00:00
Fix typos in the reference
Fix typos in the reference documentation Fixes gh-4113
This commit is contained in:
stonio
Rob Winch
parent
ab5af87953
commit
2a197c72eb
@ -58,7 +58,7 @@ At an authentication level, Spring Security supports a wide range of authenticat
|
||||
|
||||
* Authentication based on pre-established request headers (such as Computer Associates Siteminder)
|
||||
|
||||
* JA-SIG Central Authentication Service (otherwise known as CAS, which is a popular open source single sign-on system)
|
||||
* Jasig Central Authentication Service (otherwise known as CAS, which is a popular open source single sign-on system)
|
||||
|
||||
* Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol)
|
||||
|
||||
@ -70,11 +70,11 @@ At an authentication level, Spring Security supports a wide range of authenticat
|
||||
|
||||
* Java Authentication and Authorization Service (JAAS)
|
||||
|
||||
* JEE container autentication (so you can still use Container Managed Authentication if desired)
|
||||
* Java EE container authentication (so you can still use Container Managed Authentication if desired)
|
||||
|
||||
* Kerberos
|
||||
|
||||
* Java Open Source Single Sign On (JOSSO) *
|
||||
* Java Open Source Single Sign-On (JOSSO) *
|
||||
|
||||
* OpenNMS Network Management Platform *
|
||||
|
||||
@ -108,7 +108,7 @@ At an authentication level, Spring Security supports a wide range of authenticat
|
||||
|
||||
Many independent software vendors (ISVs) adopt Spring Security because of this significant choice of flexible authentication models. Doing so allows them to quickly integrate their solutions with whatever their end clients need, without undertaking a lot of engineering or requiring the client to change their environment. If none of the above authentication mechanisms suit your needs, Spring Security is an open platform and it is quite simple to write your own authentication mechanism. Many corporate users of Spring Security need to integrate with "legacy" systems that don't follow any particular security standards, and Spring Security is happy to "play nicely" with such systems.
|
||||
|
||||
Irrespective of the authentication mechanism, Spring Security provides a deep set of authorization capabilities. There are three main areas of interest - authorizing web requests, authorizing whether methods can be invoked, and authorizing access to individual domain object instances. To help you understand the differences, consider the authorization capabilities found in the Servlet Specification web pattern security, EJB Container Managed Security and file system security respectively. Spring Security provides deep capabilities in all of these important areas, which we'll explore later in this reference guide.
|
||||
Irrespective of the authentication mechanism, Spring Security provides a deep set of authorization capabilities. There are three main areas of interest: authorizing web requests, authorizing whether methods can be invoked and authorizing access to individual domain object instances. To help you understand the differences, consider the authorization capabilities found in the Servlet Specification web pattern security, EJB Container Managed Security and file system security respectively. Spring Security provides deep capabilities in all of these important areas, which we'll explore later in this reference guide.
|
||||
|
||||
|
||||
[[history]]
|
||||
@ -682,7 +682,7 @@ protected void configure(HttpSecurity http) throws Exception {
|
||||
|
||||
<1> There are multiple children to the `http.authorizeRequests()` method each matcher is considered in the order they were declared.
|
||||
<2> We specified multiple URL patterns that any user can access. Specifically, any user can access a request if the URL starts with "/resources/", equals "/signup", or equals "/about".
|
||||
<3> Any URL that starts with "/admin/" will be resticted to users who have the role "ROLE_ADMIN". You will notice that since we are invoking the `hasRole` method we do not need to specify the "ROLE_" prefix.
|
||||
<3> Any URL that starts with "/admin/" will be restricted to users who have the role "ROLE_ADMIN". You will notice that since we are invoking the `hasRole` method we do not need to specify the "ROLE_" prefix.
|
||||
<4> Any URL that starts with "/db/" requires the user to have both "ROLE_ADMIN" and "ROLE_DBA". You will notice that since we are using the `hasRole` expression we do not need to specify the "ROLE_" prefix.
|
||||
<5> Any URL that has not already been matched on only requires that the user be authenticated
|
||||
|
||||
@ -1644,7 +1644,7 @@ You should then register yourself with an OpenID provider (such as myopenid.com)
|
||||
<user name="http://jimi.hendrix.myopenid.com/" authorities="ROLE_USER" />
|
||||
----
|
||||
|
||||
You should be able to login using the `myopenid.com` site to authenticate. It is also possible to select a specific `UserDetailsService` bean for use OpenID by setting the `user-service-ref` attribute on the `openid-login` element. See the previous section on <<ns-auth-providers,authentication providers>> for more information. Note that we have omitted the password attribute from the above user configuration, since this set of user data is only being used to load the authorities for the user. A random password will be generate internally, preventing you from accidentally using this user data as an authentication source elsewhere in your configuration.
|
||||
You should be able to login using the `myopenid.com` site to authenticate. It is also possible to select a specific `UserDetailsService` bean for use OpenID by setting the `user-service-ref` attribute on the `openid-login` element. See the previous section on <<ns-auth-providers,authentication providers>> for more information. Note that we have omitted the password attribute from the above user configuration, since this set of user data is only being used to load the authorities for the user. A random password will be generated internally, preventing you from accidentally using this user data as an authentication source elsewhere in your configuration.
|
||||
|
||||
|
||||
===== Attribute Exchange
|
||||
@ -2090,7 +2090,7 @@ In Spring Security 3.0, the contents of the `spring-security-core` jar were stri
|
||||
==== SecurityContextHolder, SecurityContext and Authentication Objects
|
||||
The most fundamental object is `SecurityContextHolder`. This is where we store details of the present security context of the application, which includes details of the principal currently using the application. By default the `SecurityContextHolder` uses a `ThreadLocal` to store these details, which means that the security context is always available to methods in the same thread of execution, even if the security context is not explicitly passed around as an argument to those methods. Using a `ThreadLocal` in this way is quite safe if care is taken to clear the thread after the present principal's request is processed. Of course, Spring Security takes care of this for you automatically so there is no need to worry about it.
|
||||
|
||||
Some applications aren't entirely suitable for using a `ThreadLocal`, because of the specific way they work with threads. For example, a Swing client might want all threads in a Java Virtual Machine to use the same security context. `SecurityContextHolder` can be configured with a strategy on startup to specify how you would like the context to be stored. For a standalone application you would use the `SecurityContextHolder.MODE_GLOBAL` strategy. Other applications might want to have threads spawned by the secure thread also assume the same security identity. This is achieved by using `SecurityContextHolder.MODE_INHERITABLETHREADLOCAL`. You can change the mode from the default `SecurityContextHolder.MODE_THREADLOCAL` in two ways. The first is to set a system property, the second is to call a static method on `SecurityContextHolder`. Most applications won't need to change from the default, but if you do, take a look at the JavaDocs for `SecurityContextHolder` to learn more.
|
||||
Some applications aren't entirely suitable for using a `ThreadLocal`, because of the specific way they work with threads. For example, a Swing client might want all threads in a Java Virtual Machine to use the same security context. `SecurityContextHolder` can be configured with a strategy on startup to specify how you would like the context to be stored. For a standalone application you would use the `SecurityContextHolder.MODE_GLOBAL` strategy. Other applications might want to have threads spawned by the secure thread also assume the same security identity. This is achieved by using `SecurityContextHolder.MODE_INHERITABLETHREADLOCAL`. You can change the mode from the default `SecurityContextHolder.MODE_THREADLOCAL` in two ways. The first is to set a system property, the second is to call a static method on `SecurityContextHolder`. Most applications won't need to change from the default, but if you do, take a look at the JavaDoc for `SecurityContextHolder` to learn more.
|
||||
|
||||
|
||||
===== Obtaining information about the current user
|
||||
@ -2110,7 +2110,7 @@ String username = principal.toString();
|
||||
----
|
||||
|
||||
|
||||
The object returned by the call to `getContext()` is an instance of the `SecurityContext` interface. This is the object that is kept in thread-local storage. As we'll see below, most authentication mechanisms withing Spring Security return an instance of `UserDetails` as the principal.
|
||||
The object returned by the call to `getContext()` is an instance of the `SecurityContext` interface. This is the object that is kept in thread-local storage. As we'll see below, most authentication mechanisms within Spring Security return an instance of `UserDetails` as the principal.
|
||||
|
||||
|
||||
[[tech-userdetailsservice]]
|
||||
@ -2424,7 +2424,7 @@ If you are using the namespace, an instance of `ProviderManager` is created and
|
||||
</bean>
|
||||
----
|
||||
|
||||
In the above example we have three providers. They are tried in the order shown (which is implied by the use of a `List`), with each provider able to attempt authentication, or skip authentication by simply returning `null`. If all implementations return null, the `ProviderManager` will throw a `ProviderNotFoundException`. If you're interested in learning more about chaining providers, please refer to the `ProviderManager` JavaDocs.
|
||||
In the above example we have three providers. They are tried in the order shown (which is implied by the use of a `List`), with each provider able to attempt authentication, or skip authentication by simply returning `null`. If all implementations return null, the `ProviderManager` will throw a `ProviderNotFoundException`. If you're interested in learning more about chaining providers, please refer to the `ProviderManager` Javadoc.
|
||||
|
||||
Authentication mechanisms such as a web form-login processing filter are injected with a reference to the `ProviderManager` and will call it to handle their authentication requests. The providers you require will sometimes be interchangeable with the authentication mechanisms, while at other times they will depend on a specific authentication mechanism. For example, `DaoAuthenticationProvider` and `LdapAuthenticationProvider` are compatible with any mechanism which submits a simple username/password authentication request and so will work with form-based logins or HTTP Basic authentication. On the other hand, some authentication mechanisms create an authentication request object which can only be interpreted by a single type of `AuthenticationProvider`. An example of this would be JA-SIG CAS, which uses the notion of a service ticket and so can therefore only be authenticated by a `CasAuthenticationProvider`. You needn't be too concerned about this, because if you forget to register a suitable provider, you'll simply receive a `ProviderNotFoundException` when an attempt to authenticate is made.
|
||||
|
||||
@ -3038,7 +3038,7 @@ The http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.ht
|
||||
|
||||
[[basic]]
|
||||
== Basic and Digest Authentication
|
||||
Basic and digest authentiation are alternative authentication mechanisms which are popular in web applications. Basic authentication is often used with stateless clients which pass their credentials on each request. It's quite common to use it in combination with form-based authentication where an application is used through both a browser-based user interface and as a web-service. However, basic authentication transmits the password as plain text so it should only really be used over an encrypted transport layer such as HTTPS.
|
||||
Basic and digest authentication are alternative authentication mechanisms which are popular in web applications. Basic authentication is often used with stateless clients which pass their credentials on each request. It's quite common to use it in combination with form-based authentication where an application is used through both a browser-based user interface and as a web-service. However, basic authentication transmits the password as plain text so it should only really be used over an encrypted transport layer such as HTTPS.
|
||||
|
||||
[[basic-processing-filter]]
|
||||
=== BasicAuthenticationFilter
|
||||
@ -3069,12 +3069,12 @@ If the authentication event was successful, or authentication was not attempted
|
||||
|
||||
[[digest-processing-filter]]
|
||||
=== DigestAuthenticationFilter
|
||||
`DigestAuthenticationFilter` is capable of processing digest authentication credentials presented in HTTP headers. Digest Authentication attempts to solve many of the weaknesses of Basic authentication, specifically by ensuring credentials are never sent in clear text across the wire. Many user agents support Digest Authentication, including FireFox and Internet Explorer. The standard governing HTTP Digest Authentication is defined by RFC 2617, which updates an earlier version of the Digest Authentication standard prescribed by RFC 2069. Most user agents implement RFC 2617. Spring Security's `DigestAuthenticationFilter` is compatible with the "`auth`" quality of protection (`qop`) prescribed by RFC 2617, which also provides backward compatibility with RFC 2069. Digest Authentication is a more attractive option if you need to use unencrypted HTTP (i.e. no TLS/HTTPS) and wish to maximise security of the authentication process. Indeed Digest Authentication is a mandatory requirement for the WebDAV protocol, as noted by RFC 2518 Section 17.1.
|
||||
`DigestAuthenticationFilter` is capable of processing digest authentication credentials presented in HTTP headers. Digest Authentication attempts to solve many of the weaknesses of Basic authentication, specifically by ensuring credentials are never sent in clear text across the wire. Many user agents support Digest Authentication, including Mozilla Firefox and Internet Explorer. The standard governing HTTP Digest Authentication is defined by RFC 2617, which updates an earlier version of the Digest Authentication standard prescribed by RFC 2069. Most user agents implement RFC 2617. Spring Security's `DigestAuthenticationFilter` is compatible with the "`auth`" quality of protection (`qop`) prescribed by RFC 2617, which also provides backward compatibility with RFC 2069. Digest Authentication is a more attractive option if you need to use unencrypted HTTP (i.e. no TLS/HTTPS) and wish to maximise security of the authentication process. Indeed Digest Authentication is a mandatory requirement for the WebDAV protocol, as noted by RFC 2518 Section 17.1.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
You should not use Digest in modern applications because it is not considered secure.
|
||||
The most obvious problem is that you must store your passwords in plaintext, encrpted, or an MD5 format.
|
||||
The most obvious problem is that you must store your passwords in plaintext, encrypted, or an MD5 format.
|
||||
All of these storage formats are considered insecure.
|
||||
Instead, you should use a one way adaptive password hash (i.e. BCrypt, PBKDF2, SCrypt, etc).
|
||||
====
|
||||
@ -3092,7 +3092,7 @@ The `DigestAuthenticatonEntryPoint` has a property specifying the `key` used for
|
||||
|
||||
An appropriate value for the `nonceValiditySeconds` parameter of `DigestAuthenticationEntryPoint` depends on your application. Extremely secure applications should note that an intercepted authentication header can be used to impersonate the principal until the `expirationTime` contained in the nonce is reached. This is the key principle when selecting an appropriate setting, but it would be unusual for immensely secure applications to not be running over TLS/HTTPS in the first instance.
|
||||
|
||||
Because of the more complex implementation of Digest Authentication, there are often user agent issues. For example, Internet Explorer fails to present an "`opaque`" token on subsequent requests in the same session. Spring Security filters therefore encapsulate all state information into the "`nonce`" token instead. In our testing, Spring Security's implementation works reliably with FireFox and Internet Explorer, correctly handling nonce timeouts etc.
|
||||
Because of the more complex implementation of Digest Authentication, there are often user agent issues. For example, Internet Explorer fails to present an "`opaque`" token on subsequent requests in the same session. Spring Security filters therefore encapsulate all state information into the "`nonce`" token instead. In our testing, Spring Security's implementation works reliably with Mozilla Firefox and Internet Explorer, correctly handling nonce timeouts etc.
|
||||
|
||||
|
||||
[[digest-config]]
|
||||
@ -3202,7 +3202,7 @@ void loginSuccess(HttpServletRequest request, HttpServletResponse response,
|
||||
Authentication successfulAuthentication);
|
||||
----
|
||||
|
||||
Please refer to the JavaDocs for a fuller discussion on what the methods do, although note at this stage that `AbstractAuthenticationProcessingFilter` only calls the `loginFail()` and `loginSuccess()` methods. The `autoLogin()` method is called by `RememberMeAuthenticationFilter` whenever the `SecurityContextHolder` does not contain an `Authentication`. This interface therefore provides the underlying remember-me implementation with sufficient notification of authentication-related events, and delegates to the implementation whenever a candidate web request might contain a cookie and wish to be remembered. This design allows any number of remember-me implementation strategies. We've seen above that Spring Security provides two implementations. We'll look at these in turn.
|
||||
Please refer to the Javadoc for a fuller discussion on what the methods do, although note at this stage that `AbstractAuthenticationProcessingFilter` only calls the `loginFail()` and `loginSuccess()` methods. The `autoLogin()` method is called by `RememberMeAuthenticationFilter` whenever the `SecurityContextHolder` does not contain an `Authentication`. This interface therefore provides the underlying remember-me implementation with sufficient notification of authentication-related events, and delegates to the implementation whenever a candidate web request might contain a cookie and wish to be remembered. This design allows any number of remember-me implementation strategies. We've seen above that Spring Security provides two implementations. We'll look at these in turn.
|
||||
|
||||
==== TokenBasedRememberMeServices
|
||||
This implementation supports the simpler approach described in <<remember-me-hash-token>>. `TokenBasedRememberMeServices` generates a `RememberMeAuthenticationToken`, which is processed by `RememberMeAuthenticationProvider`. A `key` is shared between this authentication provider and the `TokenBasedRememberMeServices`. In addition, `TokenBasedRememberMeServices` requires A UserDetailsService from which it can retrieve the username and password for signature comparison purposes, and generate the `RememberMeAuthenticationToken` to contain the correct `GrantedAuthority` s. Some sort of logout command should be provided by the application that invalidates the cookie if the user requests this. `TokenBasedRememberMeServices` also implements Spring Security's `LogoutHandler` interface so can be used with `LogoutFilter` to have the cookie cleared automatically.
|
||||
@ -6295,7 +6295,7 @@ The CAS protocol supports Single Logout and can be easily added to your Spring S
|
||||
</bean>
|
||||
----
|
||||
|
||||
The `logout` element logs the user out of the local application, but does not terminate the session with the CAS server or any other applications that have been logged into. The `requestSingleLogoutFilter` filter will allow the url of `/spring_security_cas_logout` to be requested to redirect the application to the configured CAS Server logout url. Then the CAS Server will send a Single Logout request to all the services that were signed into. The `singleLogoutFilter` handles the Single Logout request by looking up the `HttpSession` in a static `Map` and then invalidating it.
|
||||
The `logout` element logs the user out of the local application, but does not terminate the session with the CAS server or any other applications that have been logged into. The `requestSingleLogoutFilter` filter will allow the URL of `/spring_security_cas_logout` to be requested to redirect the application to the configured CAS Server logout URL. Then the CAS Server will send a Single Logout request to all the services that were signed into. The `singleLogoutFilter` handles the Single Logout request by looking up the `HttpSession` in a static `Map` and then invalidating it.
|
||||
|
||||
It might be confusing why both the `logout` element and the `singleLogoutFilter` are needed. It is considered best practice to logout locally first since the `SingleSignOutFilter` just stores the `HttpSession` in a static `Map` in order to call invalidate on it. With the configuration above, the flow of logout would be:
|
||||
|
||||
@ -6417,7 +6417,7 @@ Because remoting protocols have no way of presenting themselves within the conte
|
||||
|
||||
One obvious option is to not use CAS at all for remoting protocol clients. However, this would eliminate many of the desirable features of CAS. As a middle-ground, the `CasAuthenticationProvider` uses a `StatelessTicketCache`. This is used solely for stateless clients which use a principal equal to `CasAuthenticationFilter.CAS_STATELESS_IDENTIFIER`. What happens is the `CasAuthenticationProvider` will store the resulting `CasAuthenticationToken` in the `StatelessTicketCache`, keyed on the proxy ticket. Accordingly, remoting protocol clients can present the same proxy ticket and the `CasAuthenticationProvider` will not need to contact the CAS server for validation (aside from the first request). Once authenticated, the proxy ticket could be used for URLs other than the original target service.
|
||||
|
||||
This section builds upon the previous sections to accomodate proxy ticket authentication. The first step is to specify to authenticate all artifacts as shown below.
|
||||
This section builds upon the previous sections to accommodate proxy ticket authentication. The first step is to specify to authenticate all artifacts as shown below.
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
@ -6593,7 +6593,7 @@ The Spring Security Crypto module provides support for symmetric encryption, key
|
||||
|
||||
[[spring-security-crypto-encryption]]
|
||||
=== Encryptors
|
||||
The Encryptors class provides factory methods for constructing symmetric encryptors. Using this class, you can create ByteEncryptors to encrypt data in raw byte[] form. You can also construct TextEncryptors to encrypt text strings. Encryptors are thread safe.
|
||||
The Encryptors class provides factory methods for constructing symmetric encryptors. Using this class, you can create ByteEncryptors to encrypt data in raw byte[] form. You can also construct TextEncryptors to encrypt text strings. Encryptors are thread-safe.
|
||||
|
||||
[[spring-security-crypto-encryption-bytes]]
|
||||
==== BytesEncryptor
|
||||
@ -6712,7 +6712,7 @@ assertTrue(encoder.matches("myPassword", result));
|
||||
[[concurrency]]
|
||||
== Concurrency Support
|
||||
|
||||
In most environments, Security is stored on a per `Thread` basis. This means that when work is done on a new `Thread`, the `SecurityContext` is lost. Spring Security provides some infrastructure to help make this much easier for users. Spring Security provides low level abstractions for working with Spring Security in multi threaded environments. In fact, this is what Spring Security builds on to integration with <<servletapi-start-runnable>> and <<mvc-async>>.
|
||||
In most environments, Security is stored on a per `Thread` basis. This means that when work is done on a new `Thread`, the `SecurityContext` is lost. Spring Security provides some infrastructure to help make this much easier for users. Spring Security provides low level abstractions for working with Spring Security in multi-threaded environments. In fact, this is what Spring Security builds on to integration with <<servletapi-start-runnable>> and <<mvc-async>>.
|
||||
|
||||
=== DelegatingSecurityContextRunnable
|
||||
|
||||
@ -6837,7 +6837,7 @@ Now anytime `executor.execute(Runnable)` is executed the `SecurityContext` is fi
|
||||
|
||||
=== Spring Security Concurrency Classes
|
||||
|
||||
Refer to the Javadoc for additional integrations with both the Java concurrent APIs and the Spring Task abstractions. They are quite self explanatory once you understand the previous code.
|
||||
Refer to the Javadoc for additional integrations with both the Java concurrent APIs and the Spring Task abstractions. They are quite self-explanatory once you understand the previous code.
|
||||
|
||||
* DelegatingSecurityContextCallable
|
||||
* DelegatingSecurityContextExecutor
|
||||
@ -6960,7 +6960,7 @@ public ModelAndView findMessagesForUser() {
|
||||
SecurityContextHolder.getContext().getAuthentication();
|
||||
CustomUser custom = (CustomUser) authentication == null ? null : authentication.getPrincipal();
|
||||
|
||||
// .. find messags for this user and return them ...
|
||||
// .. find messages for this user and return them ...
|
||||
}
|
||||
----
|
||||
|
||||
@ -6975,7 +6975,7 @@ import org.springframework.security.core.annotation.AuthenticationPrincipal;
|
||||
@RequestMapping("/messages/inbox")
|
||||
public ModelAndView findMessagesForUser(@AuthenticationPrincipal CustomUser customUser) {
|
||||
|
||||
// .. find messags for this user and return them ...
|
||||
// .. find messages for this user and return them ...
|
||||
}
|
||||
----
|
||||
|
||||
@ -7022,7 +7022,7 @@ import org.springframework.security.core.annotation.AuthenticationPrincipal;
|
||||
public ModelAndView updateName(@AuthenticationPrincipal(expression = "@jpaEntityManager.merge(#this)") CustomUser attachedCustomUser
|
||||
@RequestParam String firstName) {
|
||||
|
||||
// change the firstName on an atached instance which will be persisted to the database
|
||||
// change the firstName on an attached instance which will be persisted to the database
|
||||
attachedCustomUser.setFirstName(firstName);
|
||||
|
||||
// ...
|
||||
@ -7049,7 +7049,7 @@ Now that `@CurrentUser` has been specified, we can use it to signal to resolve o
|
||||
@RequestMapping("/messages/inbox")
|
||||
public ModelAndView findMessagesForUser(@CurrentUser CustomUser customUser) {
|
||||
|
||||
// .. find messags for this user and return them ...
|
||||
// .. find messages for this user and return them ...
|
||||
}
|
||||
----
|
||||
|
||||
@ -7202,7 +7202,7 @@ By exposing the `SecurityEvaluationContextExtension` bean, all of the <<common-e
|
||||
|
||||
[[appendix-schema]]
|
||||
== Security Database Schema
|
||||
There are various database schema used by the framework and this appendix provides a single reference point to them all. You only need to provide the tables for the areas of functonality you require.
|
||||
There are various database schema used by the framework and this appendix provides a single reference point to them all. You only need to provide the tables for the areas of functionality you require.
|
||||
|
||||
DDL statements are given for the HSQLDB database. You can use these as a guideline for defining the schema for the database you are using.
|
||||
|
||||
@ -7816,7 +7816,7 @@ Specifies if subdomains should be included. Default true.
|
||||
|
||||
[[nsa-hsts-max-age-seconds]]
|
||||
* **max-age-seconds**
|
||||
Specifies the maximum ammount of time the host should be considered a Known HSTS Host. Default one year.
|
||||
Specifies the maximum amount of time the host should be considered a Known HSTS Host. Default one year.
|
||||
|
||||
|
||||
[[nsa-hsts-request-matcher-ref]]
|
||||
@ -8010,7 +8010,7 @@ Do not include the header for http://en.wikipedia.org/wiki/Cross-site_scripting#
|
||||
|
||||
[[nsa-xss-protection-enabled]]
|
||||
* **xss-protection-enabled**
|
||||
Explicitly enable or eisable http://en.wikipedia.org/wiki/Cross-site_scripting#Non-Persistent[reflected / Type-1 Cross-Site Scripting (XSS)] protection.
|
||||
Explicitly enable or disable http://en.wikipedia.org/wiki/Cross-site_scripting#Non-Persistent[reflected / Type-1 Cross-Site Scripting (XSS)] protection.
|
||||
|
||||
|
||||
[[nsa-xss-protection-block]]
|
||||
@ -8956,7 +8956,7 @@ Defines the strategy use for matching incoming requests. Currently the options a
|
||||
|
||||
[[nsa-filter-security-metadata-source-use-expressions]]
|
||||
* **use-expressions**
|
||||
Enables the use of expressions in the 'access' attributes in <intercept-url> elements rather than the traditional list of configuration attributes. Defaults to 'true'. If enabled, each attribute should contain a single boolean expression. If the expression evaluates to 'true', access will be granted.
|
||||
Enables the use of expressions in the 'access' attributes in <intercept-url> elements rather than the traditional list of configuration attributes. Defaults to 'true'. If enabled, each attribute should contain a single Boolean expression. If the expression evaluates to 'true', access will be granted.
|
||||
|
||||
|
||||
[[nsa-filter-security-metadata-source-children]]
|
||||
@ -9381,7 +9381,7 @@ An external `MethodSecurityMetadataSource` instance can be supplied which will t
|
||||
* **mode**
|
||||
This attribute can be set to "aspectj" to specify that AspectJ should be used instead of the default Spring AOP. Secured methods must be woven with the `AnnotationSecurityAspect` from the `spring-security-aspects` module.
|
||||
|
||||
It is important to note that AspectJ follows Java's rule that annotations on interfaces are not inherited. This means that methods that define the Security annotaitons on the interface will not be secured. Instead, you must place the Security annotation on the class when using AspectJ.
|
||||
It is important to note that AspectJ follows Java's rule that annotations on interfaces are not inherited. This means that methods that define the Security annotations on the interface will not be secured. Instead, you must place the Security annotation on the class when using AspectJ.
|
||||
|
||||
|
||||
[[nsa-global-method-security-order]]
|
||||
@ -9444,7 +9444,7 @@ Defines a reference to a Spring bean that implements `AfterInvocationProvider`.
|
||||
|
||||
[[nsa-pre-post-annotation-handling]]
|
||||
==== <pre-post-annotation-handling>
|
||||
Allows the default expression-based mechanism for handling Spring Security's pre and post invocation annotations (@PreFilter, @PreAuthorize, @PostFilter, @PostAuthorize) to be replace entirely. Only applies if these annotations are enabled.
|
||||
Allows the default expression-based mechanism for handling Spring Security's pre and post invocation annotations (@PreFilter, @PreAuthorize, @PostFilter, @PostAuthorize) to be replaced entirely. Only applies if these annotations are enabled.
|
||||
|
||||
|
||||
[[nsa-pre-post-annotation-handling-parents]]
|
||||
@ -9597,7 +9597,7 @@ A bean identifier, used for referring to the bean elsewhere in the context.
|
||||
|
||||
[[nsa-method-security-metadata-source-use-expressions]]
|
||||
* **use-expressions**
|
||||
Enables the use of expressions in the 'access' attributes in <intercept-url> elements rather than the traditional list of configuration attributes. Defaults to 'false'. If enabled, each attribute should contain a single boolean expression. If the expression evaluates to 'true', access will be granted.
|
||||
Enables the use of expressions in the 'access' attributes in <intercept-url> elements rather than the traditional list of configuration attributes. Defaults to 'false'. If enabled, each attribute should contain a single Boolean expression. If the expression evaluates to 'true', access will be granted.
|
||||
|
||||
|
||||
[[nsa-method-security-metadata-source-children]]
|
||||
@ -9872,9 +9872,9 @@ The LDAP filter used to search for users (optional). For example "(uid={0})". Th
|
||||
|
||||
[[appendix-dependencies]]
|
||||
== Spring Security Dependencies
|
||||
This appendix provides a reference of the modules in Spring Security and the additional dependencies that they require in order to function in a running application. We don't include dependenices that are only used when building or testing Spring Security itself. Nor do we include transitive dependencies which are required by external dependencies.
|
||||
This appendix provides a reference of the modules in Spring Security and the additional dependencies that they require in order to function in a running application. We don't include dependencies that are only used when building or testing Spring Security itself. Nor do we include transitive dependencies which are required by external dependencies.
|
||||
|
||||
The version of Spring required is listed on the project website, so the specific versions are omitted for Spring dependencies below. Note that some of the dependencies listed as"optional" below may still be required for other non-security functionality in a Spring application. Also dependencies listed as "optional" may not actually be marked as such in the project's Maven pom files if they are used in most applications. They are"optional" only in the sense that you don't need them unless you are using the specified functionality.
|
||||
The version of Spring required is listed on the project website, so the specific versions are omitted for Spring dependencies below. Note that some of the dependencies listed as "optional" below may still be required for other non-security functionality in a Spring application. Also dependencies listed as "optional" may not actually be marked as such in the project's Maven POM files if they are used in most applications. They are "optional" only in the sense that you don't need them unless you are using the specified functionality.
|
||||
|
||||
Where a module depends on another Spring Security module, the non-optional dependencies of the module it depends on are also assumed to be required and are not listed separately.
|
||||
|
||||
@ -9883,7 +9883,7 @@ Where a module depends on another Spring Security module, the non-optional depen
|
||||
|
||||
The core module must be included in any project using Spring Security.
|
||||
|
||||
.Core Depenendencies
|
||||
.Core Dependencies
|
||||
|===
|
||||
| Dependency | Version | Description
|
||||
|
||||
@ -9893,7 +9893,7 @@ The core module must be included in any project using Spring Security.
|
||||
|
||||
| ehcache
|
||||
| 1.6.2
|
||||
| Required if the ehcache-based user cache implementation is used (optional).
|
||||
| Required if the Ehcache-based user cache implementation is used (optional).
|
||||
|
||||
| spring-aop
|
||||
|
|
||||
@ -10040,7 +10040,7 @@ The ACL module.
|
||||
|
||||
| ehcache
|
||||
| 1.6.2
|
||||
| Required if the ehcache-based ACL cache implementation is used (optional if you are using your own implementation).
|
||||
| Required if the Ehcache-based ACL cache implementation is used (optional if you are using your own implementation).
|
||||
|
||||
| spring-jdbc
|
||||
|
|
||||
@ -10072,7 +10072,7 @@ The CAS module provides integration with JA-SIG CAS.
|
||||
|
||||
| ehcache
|
||||
| 1.6.2
|
||||
| Required if you are using the ehcache-based ticket cache (optional).
|
||||
| Required if you are using the Ehcache-based ticket cache (optional).
|
||||
|===
|
||||
|
||||
=== spring-security-openid
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user