Minor documentation fixes

docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc

@@ -55,7 +55,7 @@ Based upon the <<authentication-password-storage-history,Password History>> sect
 However, this ignores three real world problems:
 
 - There are many applications using old password encodings that cannot easily migrate
-- The best practice for password storage will change again.
+- The best practice for password storage will change again
 - As a framework Spring Security cannot make breaking changes frequently
 
 Instead Spring Security introduces `DelegatingPasswordEncoder` which solves all of the problems by:
@@ -295,7 +295,7 @@ java.lang.IllegalArgumentException: There is no PasswordEncoder mapped for the i
 	at org.springframework.security.crypto.password.DelegatingPasswordEncoder.matches(DelegatingPasswordEncoder.java:196)
 ----
 
-The easiest way to resolve the error is to switch to explicitly provide the `PasswordEncoder` that you passwords are encoded with.
+The easiest way to resolve the error is to switch to explicitly providing the `PasswordEncoder` that your passwords are encoded with.
 The easiest way to resolve it is to figure out how your passwords are currently being stored and explicitly provide the correct `PasswordEncoder`.
 
 If you are migrating from Spring Security 4.2.x you can revert to the previous behavior by <<authentication-password-storage-configuration,exposing a `NoOpPasswordEncoder` bean>>.

docs/manual/src/docs/asciidoc/_includes/about/exploits/csrf.adoc

@@ -377,7 +377,7 @@ More information about using multipart forms with Spring can be found within the
 The first option is to include the actual CSRF token in the body of the request.
 By placing the CSRF token in the body, the body will be read before authorization is performed.
 This means that anyone can place temporary files on your server.
-However, only authorized users will be able to submit a File that is processed by your application.
+However, only authorized users will be able to submit a file that is processed by your application.
 In general, this is the recommended approach because the temporary file upload should have a negligible impact on most servers.
 
 [[csrf-considerations-multipart-url]]

docs/manual/src/docs/asciidoc/_includes/about/exploits/headers.adoc

@@ -384,7 +384,7 @@ This is a nice clean-up action to perform on logout.
 
 [NOTE]
 ====
-Refer to the relevant sections to see how to configure both <<servlet-headers-custom,servlet>> based applications.
+Refer to the relevant section to see how to configure <<servlet-headers-custom,servlet>> based applications.
 ====
 
 Spring Security has mechanisms to make it convenient to add the more common security headers to your application.

docs/manual/src/docs/asciidoc/_includes/about/exploits/http.adoc

@@ -20,7 +20,7 @@ Spring Security provides support for <<headers-hsts,Strict Transport Security>>
 == Proxy Server Configuration
 
 When using a proxy server it is important to ensure that you have configured your application properly.
-For example, many applications will have a load balancer that responds to request for https://example.com/ by forwarding the request to an application server at https://192.168.1:8080
+For example, many applications will have a load balancer that responds to request for https://example.com/ by forwarding the request to an application server at https://192.168.1:8080.
 Without proper configuration, the application server will not know that the load balancer exists and treat the request as though https://192.168.1:8080 was requested by the client.
 
 To fix this you can use https://tools.ietf.org/html/rfc7239[RFC 7239] to specify that a load balancer is being used.

docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/resource-server.adoc

@@ -121,7 +121,7 @@ This property can also be supplied directly on the <<webflux-oauth2resourceserve
 [[webflux-oauth2resourceserver-jwt-sansboot]]
 === Overriding or Replacing Boot Auto Configuration
 
-There are two `@Bean` s that Spring Boot generates on Resource Server's behalf.
+There are two ``@Bean``s that Spring Boot generates on Resource Server's behalf.
 
 The first is a `SecurityWebFilterChain` that configures the app as a resource server. When including `spring-security-oauth2-jose`, this `SecurityWebFilterChain` looks like:
 
@@ -1045,7 +1045,7 @@ fun forFoosEyesOnly(): Mono<String> {
 [[webflux-oauth2resourceserver-opaque-sansboot]]
 === Overriding or Replacing Boot Auto Configuration
 
-There are two `@Bean` s that Spring Boot generates on Resource Server's behalf.
+There are two ``@Bean``s that Spring Boot generates on Resource Server's behalf.
 
 The first is a `SecurityWebFilterChain` that configures the app as a resource server.
 When use Opaque Token, this `SecurityWebFilterChain` looks like:

docs/manual/src/docs/asciidoc/_includes/reactive/webflux.adoc

@@ -130,7 +130,7 @@ You can find more examples of explicit configuration in unit tests, by searching
 [[jc-webflux-multiple-filter-chains]]
 === Multiple Chains Support
 
-You can configure multiple `SecurityWebFilterChain` instances to separate configuration by `RequestMatcher` s.
+You can configure multiple `SecurityWebFilterChain` instances to separate configuration by ``RequestMatcher``s.
 
 For example, you can isolate configuration for URLs that start with `/api`, like so:
 

docs/manual/src/docs/asciidoc/_includes/servlet/architecture/delegating-filter-proxy.adoc

@@ -41,6 +41,6 @@ fun doFilter(request: ServletRequest, response: ServletResponse, chain: FilterCh
 ----
 ====
 
-Another benefit of `DelegatingFilterProxy` is that it allows delaying looking `Filter` bean instances.
+Another benefit of `DelegatingFilterProxy` is that it allows delaying looking `Filter` bean instances up.
 This is important because the container needs to register the `Filter` instances before the container can startup.
 However, Spring typically uses a `ContextLoaderListener` to load the Spring Beans which will not be done until after the `Filter` instances need to be registered.

docs/manual/src/docs/asciidoc/_includes/servlet/architecture/exception-translation-filter.adoc

@@ -13,7 +13,7 @@ image::{figures}/exceptiontranslationfilter.png[]
 
 * image:{icondir}/number_1.png[] First, the `ExceptionTranslationFilter` invokes `FilterChain.doFilter(request, response)` to invoke the rest of the application.
 * image:{icondir}/number_2.png[] If the user is not authenticated or it is an `AuthenticationException`, then __Start Authentication__.
-** The <<servlet-authentication-securitycontextholder>> is cleared out
+** The <<servlet-authentication-securitycontextholder>> is cleared out.
 ** The `HttpServletRequest` is saved in the {security-api-url}org/springframework/security/web/savedrequest/RequestCache.html[`RequestCache`].
 When the user successfully authenticates, the `RequestCache` is used to replay the original request.
 // FIXME: add link to authentication success

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc

@@ -14,7 +14,7 @@ You could also omit these pages from the filter chain entirely, thus bypassing t
 This is what we mean by anonymous authentication.
 Note that there is no real conceptual difference between a user who is "anonymously authenticated" and an unauthenticated user.
 Spring Security's anonymous authentication just gives you a more convenient way to configure your access-control attributes.
-Calls to servlet API calls such as `getCallerPrincipal`, for example, will still return null even though there is actually an anonymous authentication object in the `SecurityContextHolder`.
+Calls to servlet API such as `getCallerPrincipal`, for example, will still return null even though there is actually an anonymous authentication object in the `SecurityContextHolder`.
 
 There are other situations where anonymous authentication is useful, such as when an auditing interceptor queries the `SecurityContextHolder` to identify which principal was responsible for a given operation.
 Classes can be authored more robustly if they know the `SecurityContextHolder` always contains an `Authentication` object, and never `null`.
@@ -26,8 +26,8 @@ Anonymous authentication support is provided automatically when using the HTTP c
 You don't need to configure the beans described here unless you are using traditional bean configuration.
 
 Three classes that together provide the anonymous authentication feature.
-`AnonymousAuthenticationToken` is an implementation of `Authentication`, and stores the `GrantedAuthority` s which apply to the anonymous principal.
-There is a corresponding `AnonymousAuthenticationProvider`, which is chained into the `ProviderManager` so that `AnonymousAuthenticationToken` s are accepted.
+`AnonymousAuthenticationToken` is an implementation of `Authentication`, and stores the ``GrantedAuthority``s which apply to the anonymous principal.
+There is a corresponding `AnonymousAuthenticationProvider`, which is chained into the `ProviderManager` so that ``AnonymousAuthenticationToken``s are accepted.
 Finally, there is an `AnonymousAuthenticationFilter`, which is chained after the normal authentication mechanisms and automatically adds an `AnonymousAuthenticationToken` to the `SecurityContextHolder` if there is no existing `Authentication` held there.
 The definition of the filter and authentication provider appears as follows:
 
@@ -91,7 +91,7 @@ For example:
 === AuthenticationTrustResolver
 Rounding out the anonymous authentication discussion is the `AuthenticationTrustResolver` interface, with its corresponding `AuthenticationTrustResolverImpl` implementation.
 This interface provides an `isAnonymous(Authentication)` method, which allows interested classes to take into account this special type of authentication status.
-The `ExceptionTranslationFilter` uses this interface in processing `AccessDeniedException` s.
+The `ExceptionTranslationFilter` uses this interface in processing ``AccessDeniedException``s.
 If an `AccessDeniedException` is thrown, and the authentication is of an anonymous type, instead of throwing a 403 (forbidden) response, the filter will instead commence the `AuthenticationEntryPoint` so the principal can authenticate properly.
 This is a necessary distinction, otherwise principals would always be deemed "authenticated" and never be given an opportunity to login via form, basic, digest or some other normal authentication mechanism.
 

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/authentication.adoc

@@ -12,7 +12,7 @@ The `Authentication` contains:
 
 * `principal` - identifies the user.
 When authenticating with a username/password this is often an instance of <<servlet-authentication-userdetails,`UserDetails`>>.
-* `credentials` - Often a password.
+* `credentials` - often a password.
 In many cases this will be cleared after the user is authenticated to ensure it is not leaked.
 * `authorities` - the <<servlet-authentication-granted-authority,``GrantedAuthority``s>> are high level permissions the user is granted.
 A few examples are roles or scopes.

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/security-context-holder.adoc

@@ -86,4 +86,4 @@ Other applications might want to have threads spawned by the secure thread also
 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.
+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.

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/cas.adoc

@@ -23,7 +23,7 @@ Inside the WAR file you will customise the login and other single sign on pages
 When deploying a CAS 3.4 server, you will also need to specify an `AuthenticationHandler` in the `deployerConfigContext.xml` included with CAS.
 The `AuthenticationHandler` has a simple method that returns a boolean as to whether a given set of Credentials is valid.
 Your `AuthenticationHandler` implementation will need to link into some type of backend authentication repository, such as an LDAP server or database.
-CAS itself includes numerous `AuthenticationHandler` s out of the box to assist with this.
+CAS itself includes numerous ``AuthenticationHandler``s out of the box to assist with this.
 When you download and deploy the server war file, it is set up to successfully authenticate users who enter a password matching their username, which is useful for testing.
 
 Apart from the CAS server itself, the other key players are of course the secure web applications deployed throughout your enterprise.
@@ -57,7 +57,7 @@ The processing filter will construct a `UsernamePasswordAuthenticationToken` rep
 The principal will be equal to `CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER`, whilst the credentials will be the service ticket opaque value.
 This authentication request will then be handed to the configured `AuthenticationManager`.
 * The `AuthenticationManager` implementation will be the `ProviderManager`, which is in turn configured with the `CasAuthenticationProvider`.
-The `CasAuthenticationProvider` only responds to `UsernamePasswordAuthenticationToken` s containing the CAS-specific principal (such as `CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER`) and `CasAuthenticationToken` s (discussed later).
+The `CasAuthenticationProvider` only responds to ``UsernamePasswordAuthenticationToken``s containing the CAS-specific principal (such as `CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER`) and ``CasAuthenticationToken``s (discussed later).
 * `CasAuthenticationProvider` will validate the service ticket using a `TicketValidator` implementation.
 This will typically be a `Cas20ServiceTicketValidator` which is one of the classes included in the CAS client library.
 In the event the application needs to validate proxy tickets, the `Cas20ProxyTicketValidator` is used.

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/index.adoc

@@ -10,12 +10,12 @@ This section discusses:
 This section describes the main architectural components of Spring Security's used in Servlet authentication.
 If you need concrete flows that explain how these pieces fit together, look at the <<servlet-authentication-mechanisms,Authentication Mechanism>> specific sections.
 
-* <<servlet-authentication-securitycontextholder>> - The `SecurityContextHolder` is where Spring Security stores the details of who is <<authentication,authenticated>>.
+* <<servlet-authentication-securitycontextholder>> - the `SecurityContextHolder` is where Spring Security stores the details of who is <<authentication,authenticated>>.
 * <<servlet-authentication-securitycontext>> - is obtained from the `SecurityContextHolder` and contains the `Authentication` of the currently authenticated user.
-* <<servlet-authentication-authentication>> - Can be the input to `AuthenticationManager` to provide the credentials a user has provided to authenticate or the current user from the `SecurityContext`.
-* <<servlet-authentication-granted-authority>> - An authority that is granted to the principal on the `Authentication` (i.e. roles, scopes, etc.)
-* <<servlet-authentication-authenticationmanager>> -  the API that defines how Spring Security's Filters perform  <<authentication,authentication>>.
-* <<servlet-authentication-providermanager>> -  the most common implementation of `AuthenticationManager`.
+* <<servlet-authentication-authentication>> - can be the input to `AuthenticationManager` to provide the credentials a user has provided to authenticate or the current user from the `SecurityContext`.
+* <<servlet-authentication-granted-authority>> - an authority that is granted to the principal on the `Authentication` (i.e. roles, scopes, etc.)
+* <<servlet-authentication-authenticationmanager>> - the API that defines how Spring Security's Filters perform  <<authentication,authentication>>.
+* <<servlet-authentication-providermanager>> - the most common implementation of `AuthenticationManager`.
 * <<servlet-authentication-authenticationprovider>> - used by `ProviderManager` to perform a specific type of authentication.
 * <<servlet-authentication-authenticationentrypoint>> - used for requesting credentials from a client (i.e. redirecting to a log in page, sending a `WWW-Authenticate` response, etc.)
 * <<servlet-authentication-abstractprocessingfilter>> - a base `Filter` used for authentication.
@@ -30,10 +30,10 @@ This also gives a good idea of the high level flow of authentication and how pie
 * <<oauth2login,OAuth 2.0 Login>> - OAuth 2.0 Log In with OpenID Connect and non-standard OAuth 2.0 Login (i.e. GitHub)
 * <<servlet-saml2,SAML 2.0 Login>> - SAML 2.0 Log In
 * <<servlet-cas,Central Authentication Server (CAS)>> - Central Authentication Server (CAS) Support
-* <<servlet-rememberme, Remember Me>> - How to remember a user past session expiration
-* <<servlet-jaas, JAAS Authentication>> - Authenticate with JAAS
+* <<servlet-rememberme, Remember Me>> - how to remember a user past session expiration
+* <<servlet-jaas, JAAS Authentication>> - authenticate with JAAS
 * <<servlet-openid,OpenID>> - OpenID Authentication (not to be confused with OpenID Connect)
-* <<servlet-preauth>> - Authenticate with an external mechanism such as https://www.siteminder.com/[SiteMinder] or Java EE security but still use Spring Security for authorization and protection against common exploits.
+* <<servlet-preauth>> - authenticate with an external mechanism such as https://www.siteminder.com/[SiteMinder] or Java EE security but still use Spring Security for authorization and protection against common exploits.
 * <<servlet-x509,X509 Authentication>> - X509 Authentication
 
 // FIXME: Add other mechanisms