diff --git a/docs/docs.gradle b/docs/docs.gradle index 2fa31dfe05..5f4d36e30a 100644 --- a/docs/docs.gradle +++ b/docs/docs.gradle @@ -1,4 +1,4 @@ -// Docbook and Javadoc building and uploading tasks + // Docbook and Javadoc building and uploading tasks apply plugin: 'base' task docs { @@ -47,6 +47,12 @@ project('manual') { } } +task reference (type: Copy) { + dependsOn 'manual:docbook' + destinationDir = buildDir + with(project('manual').spec) +} + task apidocs(type: Javadoc) { destinationDir = new File(buildDir, 'apidocs') title = "Spring Security $version API" diff --git a/docs/faq/src/docbook/faq.xml b/docs/faq/src/docbook/faq.xml index 95f1fd45f0..1b92528087 100644 --- a/docs/faq/src/docbook/faq.xml +++ b/docs/faq/src/docbook/faq.xml @@ -282,7 +282,7 @@ Make sure you have added the listener to your web.xml file. It is essential to make sure that the Spring Security session registry is notified when a session is destroyed. Without it, the session information will not be - removed from the registry. org.springframework.security.ui.session.HttpSessionEventPublisher ]]> diff --git a/docs/manual/src/docbook/anon-auth-provider.xml b/docs/manual/src/docbook/anon-auth-provider.xml index ac9172b0a7..5a664e13fe 100644 --- a/docs/manual/src/docbook/anon-auth-provider.xml +++ b/docs/manual/src/docbook/anon-auth-provider.xml @@ -54,7 +54,7 @@ SecurityContextHolder if there is no existing Authentication held there. The definition of the filter and authentication provider appears as follows: - + @@ -89,7 +89,7 @@ InMemoryDaoImpl's userMap property. As explained earlier, the benefit of anonymous authentication is that all URI patterns can have security applied to them. For example: - + diff --git a/docs/manual/src/docbook/appendix-db-schema.xml b/docs/manual/src/docbook/appendix-db-schema.xml index 901a55d1ba..c2dd64fbe1 100644 --- a/docs/manual/src/docbook/appendix-db-schema.xml +++ b/docs/manual/src/docbook/appendix-db-schema.xml @@ -136,7 +136,7 @@ create table acl_entry (
PostgreSQL - create table acl_sid( + create table acl_sid( id bigserial not null primary key, principal boolean not null, sid varchar(100) not null, diff --git a/docs/manual/src/docbook/appendix-namespace.xml b/docs/manual/src/docbook/appendix-namespace.xml index a83180b7df..eb08fdbd5f 100644 --- a/docs/manual/src/docbook/appendix-namespace.xml +++ b/docs/manual/src/docbook/appendix-namespace.xml @@ -602,7 +602,7 @@ AuthenticationProvider implementation (or want to configure one of Spring Security's own implementations as a traditional bean for some reason, then you can use the following syntax to add it to the internal - ProviderManager's list: ProviderManager's list: diff --git a/docs/manual/src/docbook/authorization-common.xml b/docs/manual/src/docbook/authorization-common.xml index 98c140d724..716c6fdb4e 100644 --- a/docs/manual/src/docbook/authorization-common.xml +++ b/docs/manual/src/docbook/authorization-common.xml @@ -17,7 +17,7 @@ AccessDecisionManagers when making authorization decisions. GrantedAuthority is an interface with only one method: - + String getAuthority(); This method allows AccessDecisionManagers to obtain a precise @@ -63,7 +63,7 @@ final access control decisions. The AccessDecisionManager interface contains three methods: - + void decide(Authentication authentication, Object secureObject, Collection<ConfigAttribute> attrs) throws AccessDeniedException; boolean supports(ConfigAttribute attribute); @@ -112,7 +112,7 @@ based on its assessment of the votes. The AccessDecisionVoter interface has three methods: - + int vote(Authentication authentication, Object object, Collection<ConfigAttribute> attrs); boolean supports(ConfigAttribute attribute); boolean supports(Class clazz); @@ -243,7 +243,7 @@ boolean supports(Class clazz); A common services layer method we've all written at one stage or another looks like this: - public Contact getById(Integer id); + public Contact getById(Integer id); Quite often, only principals with permission to read the Contact should be allowed to obtain it. In this situation the @@ -251,7 +251,7 @@ boolean supports(Class clazz); AbstractSecurityInterceptor will not suffice. This is because the identity of the Contact is all that is available before the secure object is invoked. The AclEntryAfterInvocationProvider delivers a solution, - and is configured as follows: @@ -274,7 +274,7 @@ boolean supports(Class clazz); AclEntryAfterInvocationCollectionFilteringProvider. It is designed to remove Collection or array elements for which a principal does not have access. It never thrown an AccessDeniedException - simply - silently removes the offending elements. The provider is configured as follows: @@ -311,7 +311,7 @@ boolean supports(Class clazz); RoleHierarchyVoter, is configured with a RoleHierarchy, from which it obtains all the reachable authorities which the user is assigned. A typical configuration might look like this: - diff --git a/docs/manual/src/docbook/basic-and-digest-auth.xml b/docs/manual/src/docbook/basic-and-digest-auth.xml index ecc669daf3..0015e5dd2a 100644 --- a/docs/manual/src/docbook/basic-and-digest-auth.xml +++ b/docs/manual/src/docbook/basic-and-digest-auth.xml @@ -79,7 +79,7 @@ a "nonce". This is a value the server generates. Spring Security's nonce adopts the following format: - + base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key)) expirationTime: The date and time when the nonce expires, expressed in milliseconds @@ -120,7 +120,7 @@ DigestAuthenticationFilter in the filter chain. The application context will need to define the DigestAuthenticationFilter and its required collaborators: - diff --git a/docs/manual/src/docbook/cas-auth-provider.xml b/docs/manual/src/docbook/cas-auth-provider.xml index 20095763f0..3a369a725e 100644 --- a/docs/manual/src/docbook/cas-auth-provider.xml +++ b/docs/manual/src/docbook/cas-auth-provider.xml @@ -214,7 +214,7 @@ required. You will need to add a ServiceProperties bean to your application context. This represents your CAS service: - The following beans should be configured to commence the CAS authentication process (assuming you're using a namespace configuration): - ... @@ -262,7 +262,7 @@ to the enterprise's CAS login server. This is where the user's browser will be redirected. Next you need to add a CasAuthenticationProvider and its - collaborators: @@ -306,7 +306,7 @@ ProxyTicketReceptor by adding the following to your web application's web.xml: - + <servlet> <servlet-name>casproxy</servlet-name> <servlet-class>edu.yale.its.tp.cas.proxy.ProxyTicketReceptor</servlet-class> diff --git a/docs/manual/src/docbook/channel-security.xml b/docs/manual/src/docbook/channel-security.xml index c5f59c34f1..6cc7de4602 100644 --- a/docs/manual/src/docbook/channel-security.xml +++ b/docs/manual/src/docbook/channel-security.xml @@ -37,7 +37,7 @@ <intercept-url> element and this is the simplest (and recommended approach). To configure channel security explicitly, you would define the following the filter in - your application context: diff --git a/docs/manual/src/docbook/core-filters.xml b/docs/manual/src/docbook/core-filters.xml index c800bbb302..a6d692852e 100644 --- a/docs/manual/src/docbook/core-filters.xml +++ b/docs/manual/src/docbook/core-filters.xml @@ -199,7 +199,7 @@ xlink:href="#tech-intro-sec-context-persistence">Technical Overview chapter so you might want to re-read that section at this point. Let's first take a look at how you would configure it for use with a FilterChainProxy. A basic - configuration only requires the bean itself ]]> As we saw previously, this filter has two main tasks. It is responsible for @@ -291,7 +291,7 @@ public interface SecurityContextRepository { The login form simply contains j_username and j_password input fields, and posts to the URL that is monitored by the filter (by default this is /j_spring_security_check). The basic - filter configuration looks something like this: diff --git a/docs/manual/src/docbook/core-services.xml b/docs/manual/src/docbook/core-services.xml index ebc4eb679f..748c4b0df9 100644 --- a/docs/manual/src/docbook/core-services.xml +++ b/docs/manual/src/docbook/core-services.xml @@ -127,7 +127,7 @@ UserDetailsService interfaces. Recall that the contract for UserDetailsService is a single method: - + UserDetails loadUserByUsername(String username) throws UsernameNotFoundException; The returned UserDetails is an interface that provides @@ -153,19 +153,19 @@ Security, when you don't really want to spend time configuring databases or writing UserDetailsService implementations. For this sort of situation, a simple option is to use the user-service element - from the security namespace: namespace: ]]> This also supports the use of an external properties - file: ]]> The properties file should contain entries in the form - username=password,grantedAuthority[,grantedAuthority][,enabled|disabled] + username=password,grantedAuthority[,grantedAuthority][,enabled|disabled] For example - + jimi=jimispassword,ROLE_USER,ROLE_ADMIN,enabled bob=bobspassword,ROLE_USER,enabled
@@ -230,7 +230,7 @@ algorithm is a one-way function which produces a piece of fixed-length output data (the hash) from some input data, such as a password. As an example, the MD5 hash of the string password (in hexadecimal) is - + 5f4dcc3b5aa765d61d8327deb882cf99 A hash is one-way in the sense that it is very difficult (effectively diff --git a/docs/manual/src/docbook/domain-acls.xml b/docs/manual/src/docbook/domain-acls.xml index 5947778496..2eaaf85b83 100644 --- a/docs/manual/src/docbook/domain-acls.xml +++ b/docs/manual/src/docbook/domain-acls.xml @@ -244,7 +244,7 @@ sufficient length to accommodate all common usage scenarios. The following fragment of code shows how to create an Acl, or modify an existing - Acl:// Prepare the information we'd like in our access control entry (ACE) + Acl:// Prepare the information we'd like in our access control entry (ACE) ObjectIdentity oi = new ObjectIdentityImpl(Foo.class, new Long(44)); Sid sid = new PrincipalSid("Samantha"); Permission p = BasePermission.ADMINISTRATION; diff --git a/docs/manual/src/docbook/el-access.xml b/docs/manual/src/docbook/el-access.xml index afdc002514..0f2c75fc1a 100644 --- a/docs/manual/src/docbook/el-access.xml +++ b/docs/manual/src/docbook/el-access.xml @@ -94,7 +94,7 @@ to true. Spring Security will then expect the access attributes of the <intercept-url> elements to contain Spring EL expressions. The expressions should evaluate to a boolean, - defining whether access should be allowed or not. For example: @@ -129,21 +129,21 @@ @PreFilter, @PostAuthorize and @PostFilter. Their use is enabled through the global-method-security namespace - element:]]> + element:]]>
Access Control using <literal>@PreAuthorize</literal> and <literal>@PostAuthorize</literal> The most obviously useful annotation is @PreAuthorize which decides whether a method can actually be invoked or not. For example (from the Contacts sample - application) + application) @PreAuthorize("hasRole('ROLE_USER')") public void create(Contact contact);which means that access will only be allowed for users with the role "ROLE_USER". Obviously the same thing could easily be achieved using a traditional configuration and a simple configuration attribute for the required role. But what - about: + about: @PreAuthorize("hasPermission(#contact, 'admin')") public void deletePermission(Contact contact, Sid recipient, Permission permission);Here we're actually using a method argument as part of the expression to decide @@ -156,7 +156,7 @@ the expression, so you can also access properties on the arguments. For example, if you wanted a particular method to only allow access to a user whose username matched that of the contact, you could write - + @PreAuthorize("#contact.name == authentication.name") public void doSomething(Contact contact); Here we are accessing another built–in expression, authentication, @@ -178,7 +178,7 @@ As you may already be aware, Spring Security supports filtering of collections and arrays and this can now be achieved using expressions. This is most commonly performed on the return value of a method. For - example: @PreAuthorize("hasRole('ROLE_USER')") + example: @PreAuthorize("hasRole('ROLE_USER')") @PostFilter("hasPermission(filterObject, 'read') or hasPermission(filterObject, 'admin')") public List<Contact> getAll();When using the @PostFilter annotation, Spring Security iterates diff --git a/docs/manual/src/docbook/form-authentication.xml b/docs/manual/src/docbook/form-authentication.xml index d353c9dd1d..32840641a2 100644 --- a/docs/manual/src/docbook/form-authentication.xml +++ b/docs/manual/src/docbook/form-authentication.xml @@ -26,7 +26,7 @@ The login form simply contains j_username and j_password input fields, and posts to a URL that is monitored by the filter (by default /j_spring_security_check). You should add an - UsernamePasswordAuthenticationFilter to your application context: UsernamePasswordAuthenticationFilter to your application context: diff --git a/docs/manual/src/docbook/introduction.xml b/docs/manual/src/docbook/introduction.xml index 320f006b83..4488ffd199 100644 --- a/docs/manual/src/docbook/introduction.xml +++ b/docs/manual/src/docbook/introduction.xml @@ -300,7 +300,7 @@ ultimate documentation for a project and often the simplest place to find out how something actually works. To obtain the source for the project, use the following git command: - + git clone git://git.springsource.org/spring-security/spring-security.git diff --git a/docs/manual/src/docbook/jaas-auth-provider.xml b/docs/manual/src/docbook/jaas-auth-provider.xml index e50652a69e..4a97bd48c5 100644 --- a/docs/manual/src/docbook/jaas-auth-provider.xml +++ b/docs/manual/src/docbook/jaas-auth-provider.xml @@ -11,15 +11,15 @@ Java Authentication and Authorization Service (JAAS). This package is discussed in detail below.
- +
- - AbstractJaasAuthenticationProvider - - The AbstractJaasAuthenticationProvider is the basis for the - provided JAAS AuthenticationProvider implementations. Subclasses - must implement a method that creates the LoginContext. The - AbstractJaasAuthenticationProvider has a number of dependencies that can + + AbstractJaasAuthenticationProvider + + The AbstractJaasAuthenticationProvider is the basis for the + provided JAAS AuthenticationProvider implementations. Subclasses + must implement a method that creates the LoginContext. The + AbstractJaasAuthenticationProvider has a number of dependencies that can be injected into it that are discussed below.
@@ -93,55 +93,55 @@ an implementation-specific meaning. However, there is a TestAuthorityGranter in the unit tests that demonstrates a simple AuthorityGranter implementation. -
+
- - DefaultJaasAuthenticationProvider - - The DefaultJaasAuthenticationProvider allows a JAAS - Configuration object to be injected into it as a dependency. It then - creates a LoginContext using the injected JAAS Configuration. + + DefaultJaasAuthenticationProvider + + The DefaultJaasAuthenticationProvider allows a JAAS + Configuration object to be injected into it as a dependency. It then + creates a LoginContext using the injected JAAS Configuration. This means that DefaultJaasAuthenticationProvider is not bound any particular implementation of Configuration as JaasAuthenticationProvider is. - +
- - InMemoryConfiguration - - In order to make it easy to inject a Configuration into - DefaultJaasAuthenticationProvider, a default in memory - implementation named InMemoryConfiguration is provided. The - implementation constructor accepts a Map where each key represents a - login configuration name and the value represents an Array of - AppConfigurationEntrys. - InMemoryConfiguration also supports a default - Array of AppConfigurationEntry objects that - will be used if no mapping is found within the provided Map. For - details, refer to the class level javadoc of InMemoryConfiguration. + + InMemoryConfiguration + + In order to make it easy to inject a Configuration into + DefaultJaasAuthenticationProvider, a default in memory + implementation named InMemoryConfiguration is provided. The + implementation constructor accepts a Map where each key represents a + login configuration name and the value represents an Array of + AppConfigurationEntrys. + InMemoryConfiguration also supports a default + Array of AppConfigurationEntry objects that + will be used if no mapping is found within the provided Map. For + details, refer to the class level javadoc of InMemoryConfiguration.
- +
- - DefaultJaasAuthenticationProvider Example Configuration - - While the Spring configuration for InMemoryConfiguration can be - more verbose than the standarad JAAS configuration files, using it in conjuction with - DefaultJaasAuthenticationProvider is more flexible than - JaasAuthenticationProvider since it not dependant on the default - Configuration implementation. - An example configuration of DefaultJaasAuthenticationProvider using - InMemoryConfiguration is provided below. Note that custom implementations of - Configuration can easily be injected into - DefaultJaasAuthenticationProvider as well. - + DefaultJaasAuthenticationProvider Example Configuration + + While the Spring configuration for InMemoryConfiguration can be + more verbose than the standarad JAAS configuration files, using it in conjuction with + DefaultJaasAuthenticationProvider is more flexible than + JaasAuthenticationProvider since it not dependant on the default + Configuration implementation. + An example configuration of DefaultJaasAuthenticationProvider using + InMemoryConfiguration is provided below. Note that custom implementations of + Configuration can easily be injected into + DefaultJaasAuthenticationProvider as well. + - @@ -178,21 +178,21 @@ JaasAuthenticationProvider - The JaasAuthenticationProvider assumes the default Configuration is an instance of + The JaasAuthenticationProvider assumes the default Configuration is an instance of - ConfigFile. This assumption is made in order to attempt to update the Configuration. The - JaasAuthenticationProvider then uses the default Configuration to create the + ConfigFile. This assumption is made in order to attempt to update the Configuration. The + JaasAuthenticationProvider then uses the default Configuration to create the LoginContext. Let’s assume we have a JAAS login configuration file, /WEB-INF/login.conf, with the following contents: - + JAASTest { sample.SampleLoginModule required; }; Like all Spring Security beans, the JaasAuthenticationProvider is configured via the application context. The following definitions would correspond to - the above JAAS login configuration file: @@ -217,14 +217,14 @@ JAASTest { Running as a Subject - If configured, the JaasApiIntegrationFilter will attempt to - run as the Subject on the - JaasAuthenticationToken. This means that the - Subject can be accessed using: + If configured, the JaasApiIntegrationFilter will attempt to + run as the Subject on the + JaasAuthenticationToken. This means that the + Subject can be accessed using: - This integration can easily be configured using the + This integration can easily be configured using the jaas-api-provision attribute. This feature is useful when integrating with legacy or external API's that rely on the JAAS Subject being populated. diff --git a/docs/manual/src/docbook/ldap-auth-provider.xml b/docs/manual/src/docbook/ldap-auth-provider.xml index a8c1c44768..ec3c134799 100644 --- a/docs/manual/src/docbook/ldap-auth-provider.xml +++ b/docs/manual/src/docbook/ldap-auth-provider.xml @@ -57,7 +57,7 @@ The first thing you need to do is configure the server against which authentication should take place. This is done using the <ldap-server> element from the security namespace. This can be configured to point at an external LDAP server, - using the url attribute: url attribute: ]]> @@ -67,7 +67,7 @@ The <ldap-server> element can also be used to create an embedded server, which can be very useful for testing and demonstrations. In this - case you use it without the url attribute: url attribute: ]]> Here we've specified that the root DIT of the directory should be @@ -75,7 +75,7 @@ namespace parser will create an embedded Apache Directory server and scan the classpath for any LDIF files, which it will attempt to load into the server. You can customize this behaviour using the ldif attribute, which defines - an LDIF resource to be loaded: ]]> This makes it a lot easier to get up and running with LDAP, since it can be inconvenient to work all the time with an external server. It also insulates @@ -88,13 +88,13 @@ Using Bind Authentication - This is the most common LDAP authentication scenario. This is the most common LDAP authentication scenario. ]]> This simple example would obtain the DN for the user by substituting the user login name in the supplied pattern and attempting to bind as that user with the login password. This is OK if all your users are stored under a single node in the directory. If instead you wished to configure an LDAP search - filter to locate the user, you could use the following: ]]> If used with the server definition above, this would @@ -128,7 +128,7 @@ parameter {1} can be used if you want to filter on the login name. - So if we used the following configuration So if we used the following configuration ]]> and authenticated successfully as user ben, the subsequent @@ -286,7 +286,7 @@ Spring Bean Configuration A typical configuration, using some of the beans we've discussed here, might look - like this: @@ -323,7 +323,7 @@ from the ou attribute of each match. To configure a user search object, which uses the filter (uid=<user-login-name>) for use instead of the DN-pattern - (or in addition to it), you would configure the following bean @@ -348,7 +348,7 @@ these will normally be attributes from the user entry. The creation of the UserDetails object is controlled by the provider's UserDetailsContextMapper strategy, which is - responsible for mapping user objects to and from LDAP context data: authorities); diff --git a/docs/manual/src/docbook/namespace-config.xml b/docs/manual/src/docbook/namespace-config.xml index 89108a3f23..ee35c0276b 100644 --- a/docs/manual/src/docbook/namespace-config.xml +++ b/docs/manual/src/docbook/namespace-config.xml @@ -422,7 +422,7 @@ Ideally you would want to use a randomly generated salt value for each user, but you can use any property of the UserDetails object which is loaded by your UserDetailsService. For example, to use - the username property, you would use username property, you would use @@ -461,7 +461,7 @@ The available options are "http", "https" or "any". Using the value "any" means that either HTTP or HTTPS can be used. If your application uses non-standard ports for HTTP and/or HTTPS, you can specify - a list of port mappings as follows: ... @@ -501,7 +501,7 @@ JSESSIONID cookie by expiring it in the response to a logout request (assuming the application is deployed under the path /tutorial): - <LocationMatch "/tutorial/j_spring_security_logout"> + <LocationMatch "/tutorial/j_spring_security_logout"> Header always set Set-Cookie "JSESSIONID=;Path=/tutorial;Expires=Thu, 01 Jan 1970 00:00:00 GMT" </LocationMatch> . @@ -837,7 +837,7 @@ List<OpenIDAttribute> attributes = token.getAttributes();The security pointcut declarations which will be applied across your entire application context. You should only declare one <global-method-security> element. The following declaration - would enable support for Spring Security's @Secured: @Secured: ]]> Adding an annotation to a method (on an class or interface) would then limit @@ -858,12 +858,12 @@ List<OpenIDAttribute> attributes = token.getAttributes();The public Account post(Account account, double amount); } Support - for JSR-250 annotations can be enabled using ]]> These are standards-based and allow simple role-based constraints to be applied but do not have the power Spring Security's native annotations. To use - the new expression-based syntax, you would use ]]>and the equivalent Java code would be diff --git a/docs/manual/src/docbook/preauth.xml b/docs/manual/src/docbook/preauth.xml index c27bc124d3..30060417b4 100644 --- a/docs/manual/src/docbook/preauth.xml +++ b/docs/manual/src/docbook/preauth.xml @@ -143,7 +143,7 @@
Siteminder Example Configuration - A typical configuration using this filter would look like this: A typical configuration using this filter would look like this: diff --git a/docs/manual/src/docbook/remember-me-authentication.xml b/docs/manual/src/docbook/remember-me-authentication.xml index ebfaa0d42e..5ca9bdb90b 100644 --- a/docs/manual/src/docbook/remember-me-authentication.xml +++ b/docs/manual/src/docbook/remember-me-authentication.xml @@ -26,7 +26,7 @@ This approach uses hashing to achieve a useful remember-me strategy. In essence a cookie is sent to the browser upon successful interactive authentication, with the cookie being composed as follows: - + base64(username + ":" + expirationTime + ":" + md5Hex(username + ":" + expirationTime + ":" password + ":" + key)) @@ -46,7 +46,7 @@ section. Alternatively remember-me services should simply not be used at all. If you are familiar with the topics discussed in the chapter on namespace configuration, you can enable remember-me - authentication just by adding the <remember-me> element: <remember-me> element: ... @@ -68,7 +68,7 @@ valid login name unecessarily. There is a discussion on this in the comments section of this article. . To use the this approach with namespace configuration, you would supply a - datasource reference: ... @@ -77,7 +77,7 @@ The database should contain a persistent_logins table, created using the following SQL (or equivalent): - + create table persistent_logins (username varchar(64) not null, series varchar(64) primary key, token varchar(64) not null, diff --git a/docs/manual/src/docbook/runas-auth-provider.xml b/docs/manual/src/docbook/runas-auth-provider.xml index 7205d38a8b..594906bb81 100644 --- a/docs/manual/src/docbook/runas-auth-provider.xml +++ b/docs/manual/src/docbook/runas-auth-provider.xml @@ -34,7 +34,7 @@ Configuration A RunAsManager interface is provided by Spring Security: - + Authentication buildRunAs(Authentication authentication, Object object, List<ConfigAttribute> config); boolean supports(ConfigAttribute attribute); @@ -78,7 +78,7 @@ RunAsImplAuthenticationProvider, the hash of a key is stored in all generated tokens. The RunAsManagerImpl and RunAsImplAuthenticationProvider is created in the bean context with - the same key: + the same key: diff --git a/docs/manual/src/docbook/secured-objects.xml b/docs/manual/src/docbook/secured-objects.xml index fe19be9553..b554c9b761 100644 --- a/docs/manual/src/docbook/secured-objects.xml +++ b/docs/manual/src/docbook/secured-objects.xml @@ -28,7 +28,7 @@ Explicit MethodSecurityInterceptor Configuration You can of course configure a MethodSecurityIterceptor directly in your application context for use with one of Spring AOP's proxying - mechanisms: @@ -62,7 +62,7 @@ security. Let's first consider how the AspectJSecurityInterceptor is configured in the Spring application context: - @@ -140,7 +140,7 @@ public aspect DomainObjectInstanceSecurityAspect implements InitializingBean { You will need to configure Spring to load the aspect and wire it with the AspectJSecurityInterceptor. A bean declaration which achieves this is shown below: - diff --git a/docs/manual/src/docbook/security-filter-chain.xml b/docs/manual/src/docbook/security-filter-chain.xml index bbc5d6dd0c..214d76f0f2 100644 --- a/docs/manual/src/docbook/security-filter-chain.xml +++ b/docs/manual/src/docbook/security-filter-chain.xml @@ -26,7 +26,7 @@ and lifecycle interfaces. Spring's DelegatingFilterProxy provides the link between web.xml and the application context. When using DelegatingFilterProxy, you will see something like - this in the web.xml file: web.xml file: myFilter org.springframework.web.filter.DelegatingFilterProxy @@ -278,7 +278,7 @@ most specific patterns must again be declared first. Here's another example, for a similar situation to that above, where the application supports both a stateless RESTful API and also a normal web application which users log into using a form. - + @@ -323,7 +323,7 @@ Now that you've configured the tag libraries, refer to the individual reference guide sections for details on how to use them. Note that when using the tags, you should include the taglib reference in your JSP: - + <%@ taglib prefix='security' uri='http://www.springframework.org/security/tags' %>
diff --git a/docs/manual/src/docbook/session-mgmt.xml b/docs/manual/src/docbook/session-mgmt.xml index 127de44eb6..4e305346e7 100644 --- a/docs/manual/src/docbook/session-mgmt.xml +++ b/docs/manual/src/docbook/session-mgmt.xml @@ -40,7 +40,7 @@ AbstractAuthenticationProcessingFilter, so if you are using a customized form-login class, for example, you will need to inject it into both of these. In this case, a typical configuration, combining the namespace and custom beans might - look like this: @@ -90,7 +90,7 @@ to have another session open. To use concurrent session support, you'll need to add the following to - web.xml: web.xml: org.springframework.security.web.session.HttpSessionEventPublisher @@ -104,7 +104,7 @@ SessionRegistryImpl, and expiredUrl, which points to the page to display when a session has expired. A configuration using the namespace to create the FilterChainProxy and other default beans - might look like this: diff --git a/docs/manual/src/docbook/taglibs.xml b/docs/manual/src/docbook/taglibs.xml index 3009467eb6..e8b9123b9b 100644 --- a/docs/manual/src/docbook/taglibs.xml +++ b/docs/manual/src/docbook/taglibs.xml @@ -6,7 +6,7 @@
Declaring the Taglib To use any of the tags, you must have the security taglib declared in your JSP: - + ]]>
@@ -23,7 +23,7 @@ context (you should have web expressions enabled in your <http> namespace configuration to make sure this service is available). So, for example, you might - have<sec:authorize access="hasRole('supervisor')"> + have<sec:authorize access="hasRole('supervisor')"> This content will only be visible to users who have the "supervisor" authority in their list of <tt>GrantedAuthority</tt>s. @@ -34,7 +34,7 @@ the "supervisor" authority in their list of <tt>GrantedAuthority</tt>s. This tag can also operate in an alternative mode which allows you to define a particular URL as an attribute. If the user is allowed to invoke that URL, then the tag body will be evaluated, otherwise it will be skipped. So you might have something - like<sec:authorize url="/admin"> + like<sec:authorize url="/admin"> This content will only be visible to users who are authorized to send requests to the "/admin" URL. @@ -94,7 +94,7 @@ This content will only be visible to users who are authorized to send requests t comma-separated list of required permissions for a specified domain object. If the current user has any of those permissions, then the tag body will be evaluated. If they don't, it will be skipped. An example might - be<sec:accesscontrollist hasPermission="1,2" domainObject="someObject"> + be<sec:accesscontrollist hasPermission="1,2" domainObject="someObject"> This will be shown if the user has either of the permissions represented by the values "1" or "2" on the given object. diff --git a/docs/manual/src/docbook/technical-overview.xml b/docs/manual/src/docbook/technical-overview.xml index cc8c933d67..0d62d41c10 100644 --- a/docs/manual/src/docbook/technical-overview.xml +++ b/docs/manual/src/docbook/technical-overview.xml @@ -294,7 +294,7 @@ class SampleAuthenticationManager implements AuthenticationManager { AuthenticationManager which we've implemented here will authenticate any user whose username and password are the same. It assigns a single role to every user. The output from the above will be something - like: + like: Please enter your username: bob Please enter your password: @@ -668,7 +668,7 @@ Successfully authenticated. Security context contains: \ register a bean inside your application context to refer to the messages. An example is shown below: - diff --git a/docs/manual/src/docbook/x509-auth-provider.xml b/docs/manual/src/docbook/x509-auth-provider.xml index 928e598ab5..ec931d5abb 100644 --- a/docs/manual/src/docbook/x509-auth-provider.xml +++ b/docs/manual/src/docbook/x509-auth-provider.xml @@ -36,13 +36,13 @@ Enabling X.509 client authentication is very straightforward. Just add the <x509/> element to your http security namespace configuration. - -<http> + ... - <x509 subject-principal-regex="CN=(.*?)," user-service-ref="userService"/> + ; ... -</http> - + + ]]> The element has two optional attributes: subject-principal-regex. The regular expression used to @@ -82,15 +82,15 @@ To run tomcat with SSL support, drop the server.jks file into the tomcat conf directory and add the following connector to the server.xml file - -<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" scheme="https" secure="true" + +/> + ]]> clientAuth can also be set to want if you still want SSL connections to succeed even if the client doesn't provide a certificate. Clients which don't present a certificate won't be able to access any objects secured by