Fix the use of "s" with code blocks in docs

Author: di72nn

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/authentication/anonymous.adoc

@@ -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/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/jaas.adoc

@@ -16,7 +16,7 @@ The `AbstractJaasAuthenticationProvider` has a number of dependencies that can b
 
 [[jaas-callbackhandler]]
 ==== JAAS CallbackHandler
-Most JAAS `LoginModule` s require a callback of some sort.
+Most JAAS ``LoginModule``s require a callback of some sort.
 These callbacks are usually used to obtain the username and password from the user.
 
 In a Spring Security deployment, Spring Security is responsible for this user interaction (via the authentication mechanism).
@@ -26,26 +26,26 @@ Therefore, the JAAS package for Spring Security provides two default callback ha
 Each of these callback handlers implement `JaasAuthenticationCallbackHandler`.
 In most cases these callback handlers can simply be used without understanding the internal mechanics.
 
-For those needing full control over the callback behavior, internally `AbstractJaasAuthenticationProvider` wraps these `JaasAuthenticationCallbackHandler` s with an `InternalCallbackHandler`.
+For those needing full control over the callback behavior, internally `AbstractJaasAuthenticationProvider` wraps these ``JaasAuthenticationCallbackHandler``s with an `InternalCallbackHandler`.
 The `InternalCallbackHandler` is the class that actually implements JAAS normal `CallbackHandler` interface.
-Any time that the JAAS `LoginModule` is used, it is passed a list of application context configured `InternalCallbackHandler` s.
-If the `LoginModule` requests a callback against the `InternalCallbackHandler` s, the callback is in-turn passed to the `JaasAuthenticationCallbackHandler` s being wrapped.
+Any time that the JAAS `LoginModule` is used, it is passed a list of application context configured ``InternalCallbackHandler``s.
+If the `LoginModule` requests a callback against the ``InternalCallbackHandler``s, the callback is in-turn passed to the ``JaasAuthenticationCallbackHandler``s being wrapped.
 
 
 [[jaas-authoritygranter]]
 ==== JAAS AuthorityGranter
 JAAS works with principals.
 Even "roles" are represented as principals in JAAS.
 Spring Security, on the other hand, works with `Authentication` objects.
-Each `Authentication` object contains a single principal, and multiple `GrantedAuthority` s.
+Each `Authentication` object contains a single principal, and multiple ``GrantedAuthority``s.
 To facilitate mapping between these different concepts, Spring Security's JAAS package includes an `AuthorityGranter` interface.
 
-An `AuthorityGranter` is responsible for inspecting a JAAS principal and returning a set of `String` s, representing the authorities assigned to the principal.
+An `AuthorityGranter` is responsible for inspecting a JAAS principal and returning a set of ``String``s, representing the authorities assigned to the principal.
 For each returned authority string, the `AbstractJaasAuthenticationProvider` creates a `JaasGrantedAuthority` (which implements Spring Security's `GrantedAuthority` interface) containing the authority string and the JAAS principal that the `AuthorityGranter` was passed.
 The `AbstractJaasAuthenticationProvider` obtains the JAAS principals by firstly successfully authenticating the user's credentials using the JAAS `LoginModule`, and then accessing the `LoginContext` it returns.
 A call to `LoginContext.getSubject().getPrincipals()` is made, with each resulting principal passed to each `AuthorityGranter` defined against the `AbstractJaasAuthenticationProvider.setAuthorityGranters(List)` property.
 
-Spring Security does not include any production `AuthorityGranter` s given that every JAAS principal has an implementation-specific meaning.
+Spring Security does not include any production ``AuthorityGranter``s given that every JAAS principal has an implementation-specific meaning.
 However, there is a `TestAuthorityGranter` in the unit tests that demonstrates a simple `AuthorityGranter` implementation.
 
 
@@ -59,7 +59,7 @@ This means that `DefaultJaasAuthenticationProvider` is not bound any particular
 [[jaas-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 `AppConfigurationEntry` s.
+The implementation constructor accepts a `Map` where each key represents a login configuration name and the value represents an `Array` of ``AppConfigurationEntry``s.
 `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`.
 

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

@@ -101,7 +101,7 @@ We'll look at these in turn.
 This implementation supports the simpler approach described in <<remember-me-hash-token>>.
 `TokenBasedRememberMeServices` generates a `RememberMeAuthenticationToken`, which is processed by `RememberMeAuthenticationProvider`.
 A `key` is shared between this authentication provider and the `TokenBasedRememberMeServices`.
-In addition, `TokenBasedRememberMeServices` requires A UserDetailsService from which it can retrieve the username and password for signature comparison purposes, and generate the `RememberMeAuthenticationToken` to contain the correct `GrantedAuthority` s.
+In addition, `TokenBasedRememberMeServices` requires A UserDetailsService from which it can retrieve the username and password for signature comparison purposes, and generate the `RememberMeAuthenticationToken` to contain the correct ``GrantedAuthority``s.
 Some sort of logout command should be provided by the application that invalidates the cookie if the user requests this.
 `TokenBasedRememberMeServices` also implements Spring Security's `LogoutHandler` interface so can be used with `LogoutFilter` to have the cookie cleared automatically.
 

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc

@@ -186,7 +186,7 @@ This is the default in Servlet 3.1 and newer containers.
 
 
 When session fixation protection occurs, it results in a `SessionFixationProtectionEvent` being published in the application context.
-If you use `changeSessionId`, this protection will __also__ result in any  `javax.servlet.http.HttpSessionIdListener` s being notified, so use caution if your code listens for both events.
+If you use `changeSessionId`, this protection will __also__ result in any  ``javax.servlet.http.HttpSessionIdListener``s being notified, so use caution if your code listens for both events.
 See the <<session-mgmt,Session Management>> chapter for additional information.
 
 === SessionManagementFilter

docs/manual/src/docs/asciidoc/_includes/servlet/authorization/acls.adoc

@@ -16,7 +16,7 @@ Using Spring Security as the foundation, you have several approaches that can be
 * Write your business methods to enforce the security.
 You could consult a collection within the `Customer` domain object instance to determine which users have access.
 By using the `SecurityContextHolder.getContext().getAuthentication()`, you'll be able to access the `Authentication` object.
-* Write an `AccessDecisionVoter` to enforce the security from the `GrantedAuthority[]` s stored in the `Authentication` object.
+* Write an `AccessDecisionVoter` to enforce the security from the ``GrantedAuthority[]``s stored in the `Authentication` object.
 This would mean your `AuthenticationManager` would need to populate the `Authentication` with custom ``GrantedAuthority[]``s representing each of the `Customer` domain object instances the principal has access to.
 * Write an `AccessDecisionVoter` to enforce the security and open the target `Customer` domain object directly.
 This would mean your voter needs access to a DAO that allows it to retrieve the `Customer` object.
@@ -26,8 +26,8 @@ It would then access the `Customer` object's collection of approved users and ma
 Each one of these approaches is perfectly legitimate.
 However, the first couples your authorization checking to your business code.
 The main problems with this include the enhanced difficulty of unit testing and the fact it would be more difficult to reuse the `Customer` authorization logic elsewhere.
-Obtaining the `GrantedAuthority[]` s from the `Authentication` object is also fine, but will not scale to large numbers of `Customer` s.
-If a user might be able to access 5,000 `Customer` s (unlikely in this case, but imagine if it were a popular vet for a large Pony Club!) the amount of memory consumed and time required to construct the `Authentication` object would be undesirable.
+Obtaining the ``GrantedAuthority[]``s from the `Authentication` object is also fine, but will not scale to large numbers of ``Customer``s.
+If a user might be able to access 5,000 ``Customer``s (unlikely in this case, but imagine if it were a popular vet for a large Pony Club!) the amount of memory consumed and time required to construct the `Authentication` object would be undesirable.
 The final method, opening the `Customer` directly from external code, is probably the best of the three.
 It achieves separation of concerns, and doesn't misuse memory or CPU cycles, but it is still inefficient in that both the `AccessDecisionVoter` and the eventual business method itself will perform a call to the DAO responsible for retrieving the `Customer` object.
 Two accesses per method invocation is clearly undesirable.
@@ -91,19 +91,19 @@ Now that we've provided a basic overview of what the ACL system does, and what i
 The key interfaces are:
 
 
-* `Acl`: Every domain object has one and only one `Acl` object, which internally holds the `AccessControlEntry` s as well as knows the owner of the `Acl`.
+* `Acl`: Every domain object has one and only one `Acl` object, which internally holds the ``AccessControlEntry``s as well as knows the owner of the `Acl`.
 An Acl does not refer directly to the domain object, but instead to an `ObjectIdentity`.
 The `Acl` is stored in the ACL_OBJECT_IDENTITY table.
 
-* `AccessControlEntry`: An `Acl` holds multiple `AccessControlEntry` s, which are often abbreviated as ACEs in the framework.
+* `AccessControlEntry`: An `Acl` holds multiple ``AccessControlEntry``s, which are often abbreviated as ACEs in the framework.
 Each ACE refers to a specific tuple of `Permission`, `Sid` and `Acl`.
 An ACE can also be granting or non-granting and contain audit settings.
 The ACE is stored in the ACL_ENTRY table.
 
 * `Permission`: A permission represents a particular immutable bit mask, and offers convenience functions for bit masking and outputting information.
 The basic permissions presented above (bits 0 through 4) are contained in the `BasePermission` class.
 
-* `Sid`: The ACL module needs to refer to principals and `GrantedAuthority[]` s.
+* `Sid`: The ACL module needs to refer to principals and ``GrantedAuthority[]``s.
 A level of indirection is provided by the `Sid` interface, which is an abbreviation of "security identity".
 Common classes include `PrincipalSid` (to represent the principal inside an `Authentication` object) and `GrantedAuthoritySid`.
 The security identity information is stored in the ACL_SID table.