SEC-1343: ref manual typos

docs/manual/src/docbook/anon-auth-provider.xml

@@ -78,7 +78,7 @@
                     it is possible for an authenticating client to construct the
                         <interfacename>Authentication</interfacename> object (such as with RMI
                     invocations), then a malicious client could submit an
-                        <classname>AnonyousAuthenticationToken</classname> which it had created
+                        <classname>AnonymousAuthenticationToken</classname> which it had created
                     itself (with chosen username and authority list). If the <literal>key</literal>
                     is guessable or can be found out, then the token would be accepted by the
                     anonymous provider. This isn't a problem with normal usage but if you are using
@@ -132,7 +132,7 @@
             the use of the <classname>AuthenticatedVoter</classname> which we will see in the <link
                 xlink:href="#authz-authenticated-voter">authorization chapter</link>. It uses an
                 <interfacename>AuthenticationTrustResolver</interfacename> to process this
-            particular configuration attribute and grant access to aonymous users. The
+            particular configuration attribute and grant access to anonymous users. The
                 <classname>AuthenticatedVoter</classname> approach is more powerful, since it allows
             you to differentiate between anonymous, remember-me and fully-authenticated users. If
             you don't need this functionality though, then you can stick with

docs/manual/src/docbook/appendix-namespace.xml

@@ -453,7 +453,7 @@
     <section>
       <title>The <literal>&lt;authentication-manager&gt;</literal> Element</title>
       <para> Every Spring Security application which uses the namespace must have include this
-        element somewhere. It is resposible for registering the
+        element somewhere. It is responsible for registering the
           <interfacename>AuthenticationManager</interfacename> which provides authentication
         services to the application. It also allows you to define an alias name for the internal
         instance for use in your own configuration. Its use is described in the <link

docs/manual/src/docbook/core-services.xml

@@ -77,8 +77,8 @@
         <section xml:id="core-services-dao-provider">
             <title><literal>DaoAuthenticationProvider</literal></title>
             <para>The simplest <interfacename>AuthenticationProvider</interfacename> implemented by
-                Spring Security is <literal>DaoAuthenticationProvider</literal>, which is is also
-                one of the earliest supported by the framework. It leverages a
+                Spring Security is <literal>DaoAuthenticationProvider</literal>, which is also one
+                of the earliest supported by the framework. It leverages a
                     <interfacename>UserDetailsService</interfacename> (as a DAO) in order to lookup
                 the username, password and <interfacename>GrantedAuthority</interfacename>s. It
                 authenticates the user simply by comparing the password submitted in a
@@ -206,7 +206,7 @@
         <title>Password Encoding</title>
         <para>Spring Security's <interfacename>PasswordEncoder</interfacename> interface is used to
             support the use of passwords which are encoded in some way in persistent storage. This
-            will normally mean that the passwords are <quote>hashed</quote> using a digest alogirthm
+            will normally mean that the passwords are <quote>hashed</quote> using a digest algorithm
             such as MD5 or SHA.</para>
         <section>
             <title>What is a hash?</title>

docs/manual/src/docbook/el-access.xml

@@ -15,7 +15,7 @@
             Security uses specific classes for web and method security as the root object, in order
             to provide built-in expressions and access to values such as the current
             principal.</para>
-        <section  xml:id="el-common-built-in">
+        <section xml:id="el-common-built-in">
             <title>Common Built-In Expressions</title>
             <para>The base class for expression root objects is
                     <classname>SecurityExpressionRoot</classname>. This provides some common
@@ -79,8 +79,8 @@
                         </row>
                         <row>
                             <entry><literal>isFullyAuthenticated()</literal></entry>
-                            <entry>Returns <literal>true</literal> if the user is not an anonyous or
-                                a remember-me user</entry>
+                            <entry>Returns <literal>true</literal> if the user is not an anonymous
+                                or a remember-me user</entry>
                         </row>
                     </tbody>
                 </tgroup>
@@ -121,7 +121,7 @@
         <para>Method security is a bit more complicated than a simple allow or deny rule. Spring
             Security 3.0 introduced some new annotations in order to allow comprehensive support for
             the use of expressions.</para>
-        <section  xml:id="el-pre-post-annotations">
+        <section xml:id="el-pre-post-annotations">
             <title><literal>@Pre</literal> and <literal>@Post</literal> Annotations</title>
             <para>There are four annotations which support expression attributes to allow pre and
                 post-invocation authorization checks and also to support filtering of submitted
@@ -147,13 +147,13 @@
                     we're actually using a method argument as part of the expression to decide
                     whether the current user has the <quote>admin</quote>permission for the given
                     contact. The built-in <literal>hasPermission()</literal> expression is linked
-                    into the Spring Security ACL module through the application context, as we'll 
-                    <link xlink:href="#el-permission-evaluator">see
-                    below</link>. You can access any of the method arguments by name as expression variables, provided
-                    your code has debug information compiled in. Any Spring-EL functionality is
-                    available within 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</para>
+                    into the Spring Security ACL module through the application context, as we'll
+                        <link xlink:href="#el-permission-evaluator">see below</link>. You can access
+                    any of the method arguments by name as expression variables, provided your code
+                    has debug information compiled in. Any Spring-EL functionality is available
+                    within 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</para>
                 <programlisting>  @PreAuthorize("#contact.name == principal.name)")
   public void doSomething(Contact contact);</programlisting>
                 <para>Here we are accessing another built–in expression, which is the
@@ -196,7 +196,7 @@
                 we have already seen in use above. The <literal>filterTarget</literal> and
                     <literal>returnValue</literal> values are simple enough, but the use of the
                     <literal>hasPermission()</literal> expression warrants a closer look.</para>
-            <section  xml:id="el-permission-evaluator">
+            <section xml:id="el-permission-evaluator">
                 <title>The <interfacename>PermissionEvaluator</interfacename> interface</title>
                 <para><literal>hasPermission()</literal> expressions are delegated to an instance of
                         <interfacename>PermissionEvaluator</interfacename>. It is intended to bridge
@@ -220,18 +220,16 @@
                     long as it is consistent with how the permissions are loaded.</para>
                 <para>To use <literal>hasPermission()</literal> expressions, you have to explicitly
                     configure a <interfacename>PermissionEvaluator</interfacename> in your
-                    application context. This would look something like
-                    this:<programlisting language="xml"> <![CDATA[ <security:global-method-security pre-post-annotations="enabled">
+                    application context. This would look something like this:<programlisting language="xml"> <![CDATA[ <security:global-method-security pre-post-annotations="enabled">
     <security:expression-handler ref="expressionHandler"/>
   </security:global-method-security>
 
   <bean id="expressionHandler" 
       class="org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler">
         <property name="permissionEvaluator" ref="myPermissionEvaluator"/>
-  </bean>]]></programlisting>Where
-                        <literal>myPermissionEvaluator</literal> is the bean which implements
-                        <interfacename>PermissionEvaluator</interfacename>. Usually this will be the
-                    implementation from the ACL module which is called
+  </bean>]]></programlisting>Where <literal>myPermissionEvaluator</literal> is the bean which
+                    implements <interfacename>PermissionEvaluator</interfacename>. Usually this will
+                    be the implementation from the ACL module which is called
                         <classname>AclPermissionEvaluator</classname>. See the
                         <quote>Contacts</quote> sample application configuration for more
                     details.</para>

docs/manual/src/docbook/introduction.xml

@@ -21,10 +21,10 @@
             customisable security features.</para>
         <para>As you probably know two major areas of application security are
                 <quote>authentication</quote> and <quote>authorization</quote> (or
-                <quote>access-control</quote>). These are the the two main areas that Spring
-            Security targets. <quote>Authentication</quote> is the process of establishing a
-            principal is who they claim to be (a <quote>principal</quote> generally means a user,
-            device or some other system which can perform an action in your application).
+                <quote>access-control</quote>). These are the two main areas that Spring Security
+            targets. <quote>Authentication</quote> is the process of establishing a principal is who
+            they claim to be (a <quote>principal</quote> generally means a user, device or some
+            other system which can perform an action in your application).
                 <quote>Authorization</quote> refers to the process of deciding whether a principal
             is allowed to perform an action within your application. To arrive at the point where an
             authorization decision is needed, the identity of the principal has already been

docs/manual/src/docbook/jaas-auth-provider.xml

@@ -80,7 +80,7 @@ JAASTest {
                 internal mechanics.</para>
             
             <para>For those needing full control over the callback behavior,
-                internally <literal>JaasAutheticationProvider</literal> wraps these
+                internally <literal>JaasAuthenticationProvider</literal> wraps these
                 <literal>JaasAuthenticationCallbackHandler</literal>s with an
                 <literal>InternalCallbackHandler</literal>. The
                 <literal>InternalCallbackHandler</literal> is the class that

docs/manual/src/docbook/ldap-auth-provider.xml

@@ -254,7 +254,7 @@
             <info>
                 <title>LDAP Search Objects</title>
             </info>
-            <para>Often more a more complicated strategy than simple DN-matching is required to
+            <para>Often a more complicated strategy than simple DN-matching is required to
                 locate a user entry in the directory. This can be encapsulated in an
                     <interfacename>LdapUserSearch</interfacename> instance which can be supplied to
                 the authenticator implementations, for example, to allow them to locate a user. The
@@ -372,7 +372,7 @@ public interface UserDetailsContextMapper {
                 parameter is the name used to authenticate and the final parameter is the collection
                 of authorities loaded for the user. </para>
             <para> The way the context data is loaded varies slightly depending on the type of
-                authentication you are using. With the <classname>BindAuthenticatior</classname>,
+                authentication you are using. With the <classname>BindAuthenticator</classname>,
                 the context returned from the bind operation will be used to read the attributes,
                 otherwise the data will be read using the standard context obtained from the
                 configured <interfacename>ContextSource</interfacename> (when a search is configured

docs/manual/src/docbook/namespace-config.xml

@@ -21,13 +21,13 @@
 ]]></programlisting> This is much simpler than wiring up the equivalent Apache Directory Server
       beans. The most common alternative configuration requirements are supported by attributes on
       the <literal>ldap-server</literal> element and the user is isolated from worrying about which
-      beans they need to create and what the bean property names are. <footnote>
-        <para>You can find out more about the use of the <literal>ldap-server</literal> element in
-          the chapter on <link xlink:href="#ldap">LDAP</link>.</para>
-      </footnote>. Use of a good XML editor while editing the application context file should
-      provide information on the attributes and elements that are available. We would recommend that
-      you try out the <link xlink:href="http://www.springsource.com/products/sts">SpringSource Tool
-        Suite</link> as it has special features for working with standard Spring namespaces. </para>
+      beans they need to create and what the bean property names are. <footnote><para>You can find
+          out more about the use of the <literal>ldap-server</literal> element in the chapter on
+            <link xlink:href="#ldap">LDAP</link>.</para></footnote>. Use of a good XML editor while
+      editing the application context file should provide information on the attributes and elements
+      that are available. We would recommend that you try out the <link
+        xlink:href="http://www.springsource.com/products/sts">SpringSource Tool Suite</link> as it
+      has special features for working with standard Spring namespaces. </para>
     <para> To start using the security namespace in your application context, all you need to do is
       add the schema declaration to your application context file: <programlisting language="xml">
   <![CDATA[
@@ -61,41 +61,25 @@
       <para> The namespace is designed to capture the most common uses of the framework and provide
         a simplified and concise syntax for enabling them within an application. The design is based
         around the large-scale dependencies within the framework, and can be divided up into the
-        following areas: <itemizedlist>
-          <listitem>
-            <para>
+        following areas: <itemizedlist><listitem><para>
               <emphasis>Web/HTTP Security</emphasis> - the most complex part. Sets up the filters
               and related service beans used to apply the framework authentication mechanisms, to
-              secure URLs, render login and error pages and much more.</para>
-          </listitem>
-          <listitem>
-            <para>
+              secure URLs, render login and error pages and much
+              more.</para></listitem><listitem><para>
               <emphasis>Business Object (Method) Security</emphasis> - options for securing the
-              service layer.</para>
-          </listitem>
-          <listitem>
-            <para>
+              service layer.</para></listitem><listitem><para>
               <emphasis>AuthenticationManager</emphasis> - handles authentication requests from
-              other parts of the framework.</para>
-          </listitem>
-          <listitem>
-            <para>
+              other parts of the framework.</para></listitem><listitem><para>
               <emphasis>AccessDecisionManager</emphasis> - provides access decisions for web and
               method security. A default one will be registered, but you can also choose to use a
-              custom one, declared using normal Spring bean syntax.</para>
-          </listitem>
-          <listitem>
-            <para>
+              custom one, declared using normal Spring bean
+              syntax.</para></listitem><listitem><para>
               <emphasis>AuthenticationProvider</emphasis>s - mechanisms against which the
               authentication manager authenticates users. The namespace provides supports for
               several standard options and also a means of adding custom beans declared using a
-              traditional syntax. </para>
-          </listitem>
-          <listitem>
-            <para>
+              traditional syntax. </para></listitem><listitem><para>
               <emphasis>UserDetailsService</emphasis> - closely related to authentication providers,
-              but often also required by other beans.</para>
-          </listitem>
+              but often also required by other beans.</para></listitem>
           <!-- todo: diagram and link to other sections which describe the interfaces -->
         </itemizedlist></para>
       <para>We'll see how to configure these in the following sections.</para>
@@ -151,12 +135,12 @@
         comparison with the user's authorities should be made. In other words, a normal role-based
         check should be used. Access-control in Spring Security is not limited to the use of simple
         roles (hence the use of the prefix to differentiate between different types of security
-        attributes). We'll see later how the interpretation can vary<footnote>
-          <para>The interpretation of the comma-separated values in the <literal>access</literal>
-            attribute depends on the implementation of the <link xlink:href="#ns-access-manager"
+        attributes). We'll see later how the interpretation can vary<footnote><para>The
+            interpretation of the comma-separated values in the <literal>access</literal> attribute
+            depends on the implementation of the <link xlink:href="#ns-access-manager"
               >AccessDecisionManager</link> which is used. In Spring Security 3.0, the attribute can
-            also be populated with an <link xlink:href="#el-access">EL expression</link>.</para>
-        </footnote>.</para>
+            also be populated with an <link xlink:href="#el-access">EL
+          expression</link>.</para></footnote>.</para>
       <note>
         <para>You can use multiple <literal>&lt;intercept-url&gt;</literal> elements to define
           different access requirements for different sets of URLs, but they will be evaluated in
@@ -220,15 +204,14 @@
     <logout />
   </http>
   ]]></programlisting> These other elements are responsible for setting up form-login, basic
-          authentication and logout handling services respectively <footnote>
-            <para>In versions prior to 3.0, this list also included remember-me functionality. This
-              could cause some confusing errors with some configurations and was removed in 3.0. In
-              3.0, the addition of an <classname>AnonymousAuthenticationFilter</classname> is part
-              of the default <literal>&lt;http></literal> configuration, so the
-                <literal>&lt;anonymous /></literal> element is added regardless of whether
-                <literal>auto-config</literal> is enabled.</para>
-          </footnote> . They each have attributes which can be used to alter their behaviour.
-        </para>
+          authentication and logout handling services respectively <footnote><para>In versions prior
+              to 3.0, this list also included remember-me functionality. This could cause some
+              confusing errors with some configurations and was removed in 3.0. In 3.0, the addition
+              of an <classname>AnonymousAuthenticationFilter</classname> is part of the default
+                <literal>&lt;http></literal> configuration, so the <literal>&lt;anonymous
+                /></literal> element is added regardless of whether <literal>auto-config</literal>
+              is enabled.</para></footnote> . They each have attributes which can be used to alter
+          their behaviour. </para>
       </section>
       <section xml:id="ns-form-and-basic">
         <title>Form and Basic Login Options</title>
@@ -249,16 +232,15 @@
         </programlisting> Note that you can still use <literal>auto-config</literal>. The
             <literal>form-login</literal> element just overrides the default settings. Also note
           that we've added an extra <literal>intercept-url</literal> element to say that any
-          requests for the login page should be available to anonymous users <footnote>
-            <para>See the chapter on <link xlink:href="#anonymous">anonymous authentication</link>
-              and also the <link xlink:href="#authz-authenticated-voter">AuthenticatedVoter</link>
-              class for more details on how the value
-                <literal>IS_AUTHENTICATED_ANONYMOUSLY</literal> is processed.</para>
-          </footnote>. Otherwise the request would be matched by the pattern <literal>/**</literal>
-          and it wouldn't be possible to access the login page itself! This is a common
-          configuration error and will result in an infinite loop in the application. Spring
-          Security will emit a warning in the log if your login page appears to be secured. It is
-          also possible to have all requests matching a particular pattern bypass the security
+          requests for the login page should be available to anonymous users <footnote><para>See the
+              chapter on <link xlink:href="#anonymous">anonymous authentication</link> and also the
+                <link xlink:href="#authz-authenticated-voter">AuthenticatedVoter</link> class for
+              more details on how the value <literal>IS_AUTHENTICATED_ANONYMOUSLY</literal> is
+              processed.</para></footnote>. Otherwise the request would be matched by the pattern
+            <literal>/**</literal> and it wouldn't be possible to access the login page itself! This
+          is a common configuration error and will result in an infinite loop in the application.
+          Spring Security will emit a warning in the log if your login page appears to be secured.
+          It is also possible to have all requests matching a particular pattern bypass the security
           filter chain completely: <programlisting language="xml"><![CDATA[
   <http auto-config='true'>
     <intercept-url pattern="/css/**" filters="none"/>  
@@ -479,20 +461,14 @@
           logs in. If you don't require this protection, or it conflicts with some other
           requirement, you can control the behaviour using the
             <literal>session-fixation-protection</literal> attribute on
-            <literal>&lt;session-management&gt;</literal>, which has three options <itemizedlist>
-            <listitem>
-              <para><literal>migrateSession</literal> - creates a new session and copies the
-                existing session attributes to the new session. This is the default.</para>
-            </listitem>
-            <listitem>
-              <para><literal>none</literal> - Don't do anything. The original session will be
-                retained.</para>
-            </listitem>
-            <listitem>
-              <para><literal>newSession</literal> - Create a new "clean" session, without copying
-                the existing session data.</para>
-            </listitem>
-          </itemizedlist></para>
+            <literal>&lt;session-management&gt;</literal>, which has three options
+                  <itemizedlist><listitem><para><literal>migrateSession</literal> - creates a new
+                session and copies the existing session attributes to the new session. This is the
+                default.</para></listitem><listitem><para><literal>none</literal> - Don't do
+                anything. The original session will be
+                  retained.</para></listitem><listitem><para><literal>newSession</literal> - Create
+                a new "clean" session, without copying the existing session
+            data.</para></listitem></itemizedlist></para>
       </section>
     </section>
     <section xml:id="ns-openid">
@@ -558,112 +534,48 @@ List&lt;OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
       <para>The order of the filters is always strictly enforced when using the namespace. When the
         application context is being created, the filter beans are sorted by the namespace handling
         code and the standard Spring Security filters each have an alias in the namespace and a
-        well-known position.<note>
-          <para>In previous versions, the sorting took place after the filter instances had been
-            created, during post-processing of the application context. In version 3.0+ the sorting
-            is now done at the bean metadata level, before the classes have been instantiated. This
-            has implications for how you add your own filters to the stack as the entire filter list
-            must be known during the parsing of the <literal>&lt;http></literal> element, so the
-            syntax has changed slightly in 3.0.</para>
-        </note>The filters, aliases and namespace elements/attributes which create the filters are
-        shown in <xref linkend="filter-stack"/>. The filters are listed in the order in which they
-        occur in the filter chain. <table xml:id="filter-stack">
-          <title>Standard Filter Aliases and Ordering</title>
-          <tgroup cols="3" align="left">
-            <thead>
-              <row>
-                <entry align="center">Alias</entry>
-                <entry align="center">Filter Class</entry>
-                <entry align="center">Namespace Element or Attribute</entry>
-              </row>
-            </thead>
-            <tbody>
-              <row>
-                <entry> CHANNEL_FILTER</entry>
-                <entry><literal>ChannelProcessingFilter</literal></entry>
-                <entry><literal>http/intercept-url@requires-channel</literal></entry>
-              </row>
-              <row>
-                <entry> CONCURRENT_SESSION_FILTER</entry>
-                <entry><literal>ConcurrentSessionFilter</literal>
-                </entry>
-                <entry><literal>session-management/concurrency-control</literal></entry>
-              </row>
-              <row>
-                <entry> SECURITY_CONTEXT_FILTER</entry>
-                <entry><classname>SecurityContextPersistenceFilter</classname></entry>
-                <entry><literal>http</literal></entry>
-              </row>
-              <row>
-                <entry> LOGOUT_FILTER </entry>
-                <entry><literal>LogoutFilter</literal></entry>
-                <entry><literal>http/logout</literal></entry>
-              </row>
-              <row>
-                <entry> X509_FILTER </entry>
-                <entry><literal>X509AuthenticationFilter</literal></entry>
-                <entry><literal>http/x509</literal></entry>
-              </row>
-              <row>
-                <entry> PRE_AUTH_FILTER </entry>
-                <entry><literal>AstractPreAuthenticatedProcessingFilter</literal> Subclasses</entry>
-                <entry>N/A</entry>
-              </row>
-              <row>
-                <entry> CAS_FILTER </entry>
-                <entry><literal>CasAuthenticationFilter</literal></entry>
-                <entry>N/A</entry>
-              </row>
-              <row>
-                <entry> FORM_LOGIN_FILTER </entry>
-                <entry><literal>UsernamePasswordAuthenticationFilter</literal></entry>
-                <entry><literal>http/form-login</literal></entry>
-              </row>
-              <row>
-                <entry> BASIC_AUTH_FILTER </entry>
-                <entry><literal>BasicAuthenticationFilter</literal></entry>
-                <entry><literal>http/http-basic</literal></entry>
-              </row>
-              <row>
-                <entry> SERVLET_API_SUPPORT_FILTER</entry>
-                <entry><literal>SecurityContextHolderAwareFilter</literal></entry>
-                <entry><literal>http/@servlet-api-provision</literal></entry>
-              </row>
-              <row>
-                <entry> REMEMBER_ME_FILTER </entry>
-                <entry><classname>RememberMeAuthenticationFilter</classname></entry>
-                <entry><literal>http/remember-me</literal></entry>
-              </row>
-              <row>
-                <entry> ANONYMOUS_FILTER </entry>
-                <entry><literal>AnonymousAuthenticationFilter</literal></entry>
-                <entry><literal>http/anonymous</literal></entry>
-              </row>
-              <row>
-                <entry> SESSION_MANAGEMENT_FILTER</entry>
-                <entry><literal>SessionManagementFilter</literal></entry>
-                <entry><literal>session-management</literal></entry>
-              </row>
-              <row>
-                <entry>EXCEPTION_TRANSLATION_FILTER </entry>
-                <entry><classname>ExceptionTranslationFilter</classname></entry>
-                <entry><literal>http</literal></entry>
-              </row>
-              <row>
-                <entry> FILTER_SECURITY_INTERCEPTOR </entry>
-                <entry><classname>FilterSecurityInterceptor</classname></entry>
-                <entry><literal>http</literal></entry>
-              </row>
-              <row>
-                <entry> SWITCH_USER_FILTER </entry>
-                <entry><literal>SwitchUserFilter</literal></entry>
-                <entry>N/A</entry>
-              </row>
-            </tbody>
-          </tgroup>
-        </table> You can add your own filter to the stack, using the
-          <literal>custom-filter</literal> element and one of these names to specify the position
-        your filter should appear at: <programlisting language="xml"><![CDATA[
+        well-known position.<note><para>In previous versions, the sorting took place after the
+            filter instances had been created, during post-processing of the application context. In
+            version 3.0+ the sorting is now done at the bean metadata level, before the classes have
+            been instantiated. This has implications for how you add your own filters to the stack
+            as the entire filter list must be known during the parsing of the
+              <literal>&lt;http></literal> element, so the syntax has changed slightly in
+            3.0.</para></note>The filters, aliases and namespace elements/attributes which create
+        the filters are shown in <xref linkend="filter-stack"/>. The filters are listed in the order
+        in which they occur in the filter chain. <table xml:id="filter-stack"><title>Standard Filter
+            Aliases and Ordering</title><tgroup cols="3" align="left"><thead><row><entry
+                  align="center">Alias</entry><entry align="center">Filter Class</entry><entry
+                  align="center">Namespace Element or
+                  Attribute</entry></row></thead><tbody><row><entry>
+                    CHANNEL_FILTER</entry><entry><literal>ChannelProcessingFilter</literal></entry><entry><literal>http/intercept-url@requires-channel</literal></entry></row><row><entry>
+                  CONCURRENT_SESSION_FILTER</entry><entry><literal>ConcurrentSessionFilter</literal>
+                </entry><entry><literal>session-management/concurrency-control</literal></entry></row><row><entry>
+                  SECURITY_CONTEXT_FILTER</entry><entry><classname>SecurityContextPersistenceFilter</classname></entry><entry><literal>http</literal></entry></row><row><entry>
+                  LOGOUT_FILTER
+                    </entry><entry><literal>LogoutFilter</literal></entry><entry><literal>http/logout</literal></entry></row><row><entry>
+                  X509_FILTER
+                    </entry><entry><literal>X509AuthenticationFilter</literal></entry><entry><literal>http/x509</literal></entry></row><row><entry>
+                  PRE_AUTH_FILTER
+                    </entry><entry><literal>AstractPreAuthenticatedProcessingFilter</literal>
+                  Subclasses</entry><entry>N/A</entry></row><row><entry> CAS_FILTER
+                    </entry><entry><literal>CasAuthenticationFilter</literal></entry><entry>N/A</entry></row><row><entry>
+                  FORM_LOGIN_FILTER
+                    </entry><entry><literal>UsernamePasswordAuthenticationFilter</literal></entry><entry><literal>http/form-login</literal></entry></row><row><entry>
+                  BASIC_AUTH_FILTER
+                  </entry><entry><literal>BasicAuthenticationFilter</literal></entry><entry><literal>http/http-basic</literal></entry></row><row><entry>
+                  SERVLET_API_SUPPORT_FILTER</entry><entry><literal>SecurityContextHolderAwareFilter</literal></entry><entry><literal>http/@servlet-api-provision</literal></entry></row><row><entry>
+                  REMEMBER_ME_FILTER
+                    </entry><entry><classname>RememberMeAuthenticationFilter</classname></entry><entry><literal>http/remember-me</literal></entry></row><row><entry>
+                  ANONYMOUS_FILTER
+                  </entry><entry><literal>AnonymousAuthenticationFilter</literal></entry><entry><literal>http/anonymous</literal></entry></row><row><entry>
+                  SESSION_MANAGEMENT_FILTER</entry><entry><literal>SessionManagementFilter</literal></entry><entry><literal>session-management</literal></entry></row><row><entry>EXCEPTION_TRANSLATION_FILTER
+                    </entry><entry><classname>ExceptionTranslationFilter</classname></entry><entry><literal>http</literal></entry></row><row><entry>
+                  FILTER_SECURITY_INTERCEPTOR
+                    </entry><entry><classname>FilterSecurityInterceptor</classname></entry><entry><literal>http</literal></entry></row><row><entry>
+                  SWITCH_USER_FILTER
+                  </entry><entry><literal>SwitchUserFilter</literal></entry><entry>N/A</entry></row></tbody></tgroup></table>
+        You can add your own filter to the stack, using the <literal>custom-filter</literal> element
+        and one of these names to specify the position your filter should appear at: <programlisting language="xml"><![CDATA[
   <http>
      <custom-filter position="FORM_LOGIN_FILTER" ref="myFilter" />
   </http>
@@ -815,12 +727,12 @@ List&lt;OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
     <para> The main interface which provides authentication services in Spring Security is the
         <interfacename>AuthenticationManager</interfacename>. This is usually an instance of Spring
       Security's <classname>ProviderManager</classname> class, which you may already be familiar
-      with if you've used the framework before. If not, it will be covered later, in <link
-        xlink:href="#tech-intro-authentication"/>. The bean instance is registered using the
-        <literal>authentication-manager</literal> namespace element. You can't use a custom
-        <classname>AuthenticationManager</classname> if you are using either HTTP or method security
-      through the namespace, but this should not be a problem as you have full control over the
-        <classname>AuthenticationProvider</classname>s that are used.</para>
+      with if you've used the framework before. If not, it will be covered later, in the <link
+        xlink:href="#tech-intro-authentication">technical overview chapter</link>. The bean instance
+      is registered using the <literal>authentication-manager</literal> namespace element. You can't
+      use a custom <classname>AuthenticationManager</classname> if you are using either HTTP or
+      method security through the namespace, but this should not be a problem as you have full
+      control over the <classname>AuthenticationProvider</classname>s that are used.</para>
     <para> You may want to register additional <classname>AuthenticationProvider</classname> beans
       with the <classname>ProviderManager</classname> and you can do this using the
         <literal>&lt;authentication-provider&gt;</literal> element with the <literal>ref</literal>

docs/manual/src/docbook/preauth.xml

@@ -26,7 +26,7 @@
       in a structured fashion, without having to write everything from scratch. You don't need to
       know about these classes if you want to use something like <link xlink:href="#x509">X.509
         authentication</link>, as it already has a namespace configuration option which is simpler
-      to use and get started with. If you need to use explicit bean confiuration or are planning on
+      to use and get started with. If you need to use explicit bean configuration or are planning on
       writing your own implementation then an understanding of how the provided implementations work
       will be useful. You will find classes under the
         <package>org.springframework.security.web.authentication.preauth</package>. We just provide
@@ -122,7 +122,7 @@
     <section>
       <title>Request-Header Authentication (Siteminder)</title>
       <para> An external authentication system may supply information to the application by setting
-        specific headers on the HTTP request. A well known example of this is is Siteminder, which
+        specific headers on the HTTP request. A well known example of this is Siteminder, which
         passes the username in a header called <literal>SM_USER</literal>. This mechanism is
         supported by the class <classname>RequestHeaderAuthenticationFilter</classname> which simply
         extracts the username from the header. It defaults to using the name
@@ -132,7 +132,7 @@
           checks at all and it is <emphasis>extremely</emphasis> important that the external system
           is configured properly and protects all access to the application. If an attacker is able
           to forge the headers in their original request without this being detected then they could
-          potentially choose any userame they wished. </para>
+          potentially choose any username they wished. </para>
       </tip>
       <section>
         <title>Siteminder Example Configuration</title>
@@ -177,7 +177,7 @@ class="org.springframework.security.web.authentication.preauth.PreAuthenticatedA
       <title>J2EE Container Authentication</title>
       <para> The class <classname>J2eePreAuthenticatedProcessingFilter</classname> will extract the
         username from the <literal>userPrincipal</literal> property of the
-          <interfacename>HttpServletRequest</interfacename>. use of this filter would usually be
+          <interfacename>HttpServletRequest</interfacename>. Use of this filter would usually be
         combined with the use of J2EE roles as described above in <xref
           linkend="j2ee-preauth-details"/>. </para>
       <para> There is a sample application in the codebase which uses this approach, so get hold of

docs/manual/src/docbook/remember-me-authentication.xml

@@ -64,12 +64,11 @@
         <para>This approach is based on the article <link
                 xlink:href="http://jaspan.com/improved_persistent_login_cookie_best_practice"
                 >http://jaspan.com/improved_persistent_login_cookie_best_practice</link> with some
-            minor modifications <footnote>
-                <para>Essentially, the username is not included in the cookie, to prevent exposing a
-                    valid login name unecessarily. There is a discussion on this in the comments
-                    section of this article.</para>
-            </footnote>. To use the this approach with namespace configuration, you would supply a
-            datasource reference: <programlisting><![CDATA[
+            minor modifications <footnote><para>Essentially, the username is not included in the
+                    cookie, to prevent exposing a valid login name unecessarily. There is a
+                    discussion on this in the comments section of this article.</para></footnote>.
+            To use the this approach with namespace configuration, you would supply a datasource
+            reference: <programlisting><![CDATA[
   <http>
     ...
     <remember-me data-source-ref="someDataSource"/>
@@ -110,7 +109,7 @@
             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 thes in turn.</para>
+            provides two implementations. We'll look at these in turn.</para>
         <section>
             <title>TokenBasedRememberMeServices</title>
             <para> This implementation supports the simpler approach described in <xref
@@ -162,16 +161,12 @@
             <para> This class can be used in the same way as
                     <classname>TokenBasedRememberMeServices</classname>, but it additionally needs
                 to be configured with a <interfacename>PersistentTokenRepository</interfacename> to
-                store the tokens. There are two standard implementations. <itemizedlist>
-                    <listitem>
-                        <para><classname>InMemoryTokenRepositoryImpl</classname> which is intended
-                            for testing only.</para>
-                    </listitem>
-                    <listitem>
-                        <para><classname>JdbcTokenRepositoryImpl</classname> which stores the tokens
-                            in a database. </para>
-                    </listitem>
-                </itemizedlist> The database schema is described above in <xref
+                store the tokens. There are two standard implementations.
+                                <itemizedlist><listitem><para><classname>InMemoryTokenRepositoryImpl</classname>
+                            which is intended for testing
+                                only.</para></listitem><listitem><para><classname>JdbcTokenRepositoryImpl</classname>
+                            which stores the tokens in a database. </para></listitem></itemizedlist>
+                The database schema is described above in <xref
                     linkend="remember-me-persistent-token"/>. </para>
         </section>
     </section>

docs/manual/src/docbook/secured-objects.xml

@@ -24,7 +24,7 @@
         <literal>&lt;intercept-methods&gt;</literal> or <literal>&lt;protect-point&gt;</literal>
       elements. Other implementations will be used to handle annotation-based configuration. </para>
     <section>
-      <title>Explicit MethodSecurityIterceptor Configuration</title>
+      <title>Explicit MethodSecurityInterceptor Configuration</title>
       <para> You can of course configure a <classname>MethodSecurityIterceptor</classname> directly
         in your application context for use with one of Spring AOP's proxying mechanisms: <programlisting><![CDATA[
 <bean id="bankManagerSecurity"

docs/manual/src/docbook/session-mgmt.xml

@@ -13,7 +13,7 @@
     <title>SessionManagementFilter</title>
     <para>The <classname>SessionManagementFilter</classname> checks the contents of the
         <interfacename>SecurityContextRepository</interfacename> against the current contents of the
-        <classname>SecurityContextHolder</classname> to deterine whether a user has been
+        <classname>SecurityContextHolder</classname> to determine whether a user has been
       authenticated during the current request, typically by a non-interactive authentication
       mechanism, such as pre-authentication or remember-me <footnote><para>Authentication by
           mechanisms which perform a redirect after authenticating (such as form-login) will not be

docs/manual/src/docbook/technical-overview.xml

@@ -46,7 +46,7 @@
         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.
           <classname>SecurityContextHolder</classname> can be configured with a strategy on startup
-        to specify how you would like the contex to be stored. For a standalone application you
+        to specify how you would like the context to be stored. For a standalone application you
         would use the <literal>SecurityContextHolder.MODE_GLOBAL</literal> strategy. Other
         applications might want to have threads spawned by the secure thread also assume the same
         security identity. This is achieved by using
@@ -76,7 +76,7 @@ if (principal instanceof UserDetails) {
 }</programlisting>
         <para>The object returned by the call to <methodname>getContext()</methodname> is an
           instance of the <interfacename>SecurityContext</interfacename> interface. This is the
-          object that is kept in thread-local storage. As we'll see below, Most authentication
+          object that is kept in thread-local storage. As we'll see below, most authentication
           mechanisms withing Spring Security return an instance of
             <interfacename>UserDetails</interfacename> as the principal. </para>
       </section>
@@ -189,50 +189,31 @@ if (principal instanceof UserDetails) {
       own proprietary authentication system. </para>
     <section>
       <title>What is authentication in Spring Security?</title>
-      <para> Let's consider a standard authentication scenario that everyone is familiar with. <orderedlist>
-          <listitem>
-            <para>A user is prompted to log in with a username and password.</para>
-          </listitem>
-          <listitem>
-            <para>The system (successfully) verifies that the password is correct for the
-              username.</para>
-          </listitem>
-          <listitem>
-            <para>The context information for that user is obtained (their list of roles and so
-              on).</para>
-          </listitem>
-          <listitem>
-            <para>A security context is established for the user</para>
-          </listitem>
-          <listitem>
-            <para>The user proceeds, potentially to perform some operation which is potentially
-              protected by an access control mechanism which checks the required permissions for the
-              operation against the current security context information. </para>
-          </listitem>
-        </orderedlist> The first three items constitute the authentication process so we'll take a
-        look at how these take place within Spring Security.<orderedlist>
-          <listitem>
-            <para>The username and password are obtained and combined into an instance of
+      <para> Let's consider a standard authentication scenario that everyone is familiar with.
+              <orderedlist><listitem><para>A user is prompted to log in with a username and
+              password.</para></listitem><listitem><para>The system (successfully) verifies that the
+              password is correct for the username.</para></listitem><listitem><para>The context
+              information for that user is obtained (their list of roles and so
+            on).</para></listitem><listitem><para>A security context is established for the
+              user</para></listitem><listitem><para>The user proceeds, potentially to perform some
+              operation which is potentially protected by an access control mechanism which checks
+              the required permissions for the operation against the current security context
+              information. </para></listitem></orderedlist> The first three items constitute the
+        authentication process so we'll take a look at how these take place within Spring
+              Security.<orderedlist><listitem><para>The username and password are obtained and
+              combined into an instance of
                 <classname>UsernamePasswordAuthenticationToken</classname> (an instance of the
                 <interfacename>Authentication</interfacename> interface, which we saw
-              earlier).</para>
-          </listitem>
-          <listitem>
-            <para>The token is passed to an instance of
-                <interfacename>AuthenticationManager</interfacename> for validation.</para>
-          </listitem>
-          <listitem>
-            <para>The <interfacename>AuthenticationManager</interfacename> returns a fully populated
+              earlier).</para></listitem><listitem><para>The token is passed to an instance of
+                <interfacename>AuthenticationManager</interfacename> for
+            validation.</para></listitem><listitem><para>The
+                <interfacename>AuthenticationManager</interfacename> returns a fully populated
                 <interfacename>Authentication</interfacename> instance on successful
-              authentication.</para>
-          </listitem>
-          <listitem>
-            <para>The security context is established by calling
-                <code>SecurityContextHolder.getContext().setAuthentication(...)</code>, passing in
-              the returned authentication object.</para>
-          </listitem>
-        </orderedlist>From that point on, the user is considered to be authenticated. Let's look at
-        some code as an example.
+              authentication.</para></listitem><listitem><para>The security context is established
+              by calling <code>SecurityContextHolder.getContext().setAuthentication(...)</code>,
+              passing in the returned authentication object.</para></listitem></orderedlist>From
+        that point on, the user is considered to be authenticated. Let's look at some code as an
+        example.
         <programlisting language="java">import org.springframework.security.authentication.*;
 import org.springframework.security.core.*;
 import org.springframework.security.core.authority.GrantedAuthorityImpl;
@@ -375,7 +356,7 @@ Successfully authenticated. Security context contains: \
       The main participants (in the order that they are used) are the
         <classname>ExceptionTranslationFilter</classname>, an
         <interfacename>AuthenticationEntryPoint</interfacename> and an <quote>authentication
-        mechanism</quote>, which is resposible for calling the
+        mechanism</quote>, which is responsible for calling the
         <classname>AuthenticationManager</classname> which we saw in the previous section.</para>
     <section>
       <title>ExceptionTranslationFilter</title>
@@ -461,7 +442,7 @@ Successfully authenticated. Security context contains: \
   </section>
   <section xml:id="tech-intro-access-control">
     <title>Access-Control (Authorization) in Spring Security</title>
-    <para> The main interface resposible for making access-control decisions in Spring Security is
+    <para> The main interface responsible for making access-control decisions in Spring Security is
       the <interfacename>AccessDecisionManager</interfacename>. It has a
         <methodname>decide</methodname> method which takes an
         <interfacename>Authentication</interfacename> object representing the principal requesting
@@ -503,29 +484,17 @@ Successfully authenticated. Security context contains: \
           <interfacename>Authentication</interfacename> if the principal has been
         authenticated.</para>
       <para><classname>AbstractSecurityInterceptor</classname> provides a consistent workflow for
-        handling secure object requests, typically: <orderedlist>
-          <listitem>
-            <para>Look up the <quote>configuration attributes</quote> associated with the present
-              request</para>
-          </listitem>
-          <listitem>
-            <para>Submitting the secure object, current
+        handling secure object requests, typically: <orderedlist><listitem><para>Look up the
+                <quote>configuration attributes</quote> associated with the present
+            request</para></listitem><listitem><para>Submitting the secure object, current
                 <interfacename>Authentication</interfacename> and configuration attributes to the
                 <interfacename>AccessDecisionManager</interfacename> for an authorization
-              decision</para>
-          </listitem>
-          <listitem>
-            <para>Optionally change the <interfacename>Authentication</interfacename> under which
-              the invocation takes place</para>
-          </listitem>
-          <listitem>
-            <para>Allow the secure object invocation to proceed (assuming access was granted)</para>
-          </listitem>
-          <listitem>
-            <para>Call the <interfacename>AfterInvocationManager</interfacename> if configured, once
-              the invocation has returned.</para>
-          </listitem>
-        </orderedlist></para>
+              decision</para></listitem><listitem><para>Optionally change the
+                <interfacename>Authentication</interfacename> under which the invocation takes
+              place</para></listitem><listitem><para>Allow the secure object invocation to proceed
+              (assuming access was granted)</para></listitem><listitem><para>Call the
+                <interfacename>AfterInvocationManager</interfacename> if configured, once the
+              invocation has returned.</para></listitem></orderedlist></para>
       <section xml:id="tech-intro-config-attributes">
         <title>What are Configuration Attributes?</title>
         <para> A <quote>configuration attribute</quote> can be thought of as a String that has
@@ -550,9 +519,9 @@ Successfully authenticated. Security context contains: \
             <interfacename>AccessDecisionManager</interfacename> implementation. The use of the
           prefix <literal>ROLE_</literal> is a marker to indicate that these attributes are roles
           and should be consumed by Spring Security's <classname>RoleVoter</classname>. This is only
-          relevant when a voter-based  <interfacename>AccessDecisionManager</interfacename> is in
-          use. We'll see how the  <interfacename>AccessDecisionManager</interfacename> is
-          implemented in the <link xlink:href="authz-arch">authorization chapter</link>.</para>
+          relevant when a voter-based <interfacename>AccessDecisionManager</interfacename> is in
+          use. We'll see how the <interfacename>AccessDecisionManager</interfacename> is implemented
+          in the <link xlink:href="authz-arch">authorization chapter</link>.</para>
       </section>
       <section>
         <title>RunAsManager</title>
@@ -583,14 +552,10 @@ Successfully authenticated. Security context contains: \
           or not change it in any way as it chooses.</para>
         <para><classname>AbstractSecurityInterceptor</classname> and its related objects are shown
           in <xref linkend="abstract-security-interceptor"/>. <figure
-            xml:id="abstract-security-interceptor">
-            <title>Security interceptors and the <quote>secure object</quote> model</title>
-            <mediaobject>
-              <imageobject>
+            xml:id="abstract-security-interceptor"><title>Security interceptors and the
+                <quote>secure object</quote> model</title><mediaobject><imageobject>
                 <imagedata align="center" fileref="images/security-interception.png" format="PNG"/>
-              </imageobject>
-            </mediaobject>
-          </figure></para>
+              </imageobject></mediaobject></figure></para>
       </section>
       <section>
         <title>Extending the Secure Object Model</title>