Fix Asciidoctor Warnings

Closes gh-7973

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

@@ -51,7 +51,7 @@ The short term credential can be validated quickly without any loss in security.
 == DelegatingPasswordEncoder
 
 Prior to Spring Security 5.0 the default `PasswordEncoder` was `NoOpPasswordEncoder` which required plain text passwords.
-Based upon the <<password-history,Password History>> section you might expect that the default `PasswordEncoder` is now something like `BCryptPasswordEncoder`.
+Based upon the <<authentication-password-storage-history,Password History>> section you might expect that the default `PasswordEncoder` is now something like `BCryptPasswordEncoder`.
 However, this ignores three real world problems:
 
 - There are many applications using old password encodings that cannot easily migrate
@@ -101,7 +101,7 @@ The general format for a password is:
 
 .DelegatingPasswordEncoder Storage Format
 ====
-[source,text]
+[source,text,attrs="-attributes"]
 ----
 {id}encodedPassword
 ----
@@ -115,7 +115,7 @@ All of the original passwords are "password".
 
 .DelegatingPasswordEncoder Encoded Passwords Example
 ====
-[source,text]
+[source,text,attrs="-attributes"]
 ----
 {bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG // <1>
 {noop}password // <2>
@@ -148,12 +148,12 @@ For example, BCrypt passwords often start with `$2a$`.
 === Password Encoding
 
 The `idForEncode` passed into the constructor determines which `PasswordEncoder` will be used for encoding passwords.
-In the `DelegatingPasswordEncoder` we constructed above, that means that the result of encoding `password` would be delegated to `BCryptPasswordEncoder` and be prefixed with `{bcrypt}`.
+In the `DelegatingPasswordEncoder` we constructed above, that means that the result of encoding `password` would be delegated to `BCryptPasswordEncoder` and be prefixed with `+{bcrypt}+`.
 The end result would look like:
 
 .DelegatingPasswordEncoder Encode Example
 ====
-[source,text]
+[source,text,attrs="-attributes"]
 ----
 {bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
 ----
@@ -162,7 +162,7 @@ The end result would look like:
 [[authentication-password-storage-dpe-matching]]
 === Password Matching
 
-Matching is done based upon the `{id}` and the mapping of the `id` to the `PasswordEncoder` provided in the constructor.
+Matching is done based upon the `+{id}+` and the mapping of the `id` to the `PasswordEncoder` provided in the constructor.
 Our example in <<authentication-password-storage-dpe-format,Password Storage Format>> provides a working example of how this is done.
 By default, the result of invoking `matches(CharSequence, String)` with a password and an `id` that is not mapped (including a null id) will result in an `IllegalArgumentException`.
 This behavior can be customized using `DelegatingPasswordEncoder.setDefaultPasswordEncoderForMatches(PasswordEncoder)`.
@@ -180,7 +180,7 @@ There are convenience mechanisms to make this easier, but this is still not inte
 
 .withDefaultPasswordEncoder Example
 ====
-[source,java]
+[source,java,attrs="-attributes"]
 ----
 User user = User.withDefaultPasswordEncoder()
   .username("user")
@@ -225,7 +225,7 @@ For example, the following will encode the password of `password` for use with <
 
 .Spring Boot CLI encodepassword Example
 ====
-[source]
+[source,attrs="-attributes"]
 ----
 spring encodepassword password
 {bcrypt}$2a$10$X5wFBtLrL/kHcmrOGGTrGufsBX8CJ0WpQpF3pgeuxBB/H73BK1DW6
@@ -235,7 +235,7 @@ spring encodepassword password
 [[authentication-password-storage-dpe-troubleshoot]]
 === Troubleshooting
 
-The following error occurs when one of the passwords that are stored has no id as described in <<pe-dpe-format>>.
+The following error occurs when one of the passwords that are stored has no id as described in <<authentication-password-storage-dpe-format>>.
 
 ----
 java.lang.IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"
@@ -257,6 +257,8 @@ $2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
 
 to
 
+
+[source,attrs="-attributes"]
 ----
 {bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
 ----

docs/manual/src/docs/asciidoc/_includes/about/getting-spring-security.adoc

@@ -276,7 +276,7 @@ dependencies {
 
 If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate <<modules>>.
 
-Spring Security builds against Spring Framework {spring-core-version} but should generally work with any newer version of Spring Framework 5.x. {JB}
+Spring Security builds against Spring Framework {spring-core-version} but should generally work with any newer version of Spring Framework 5.x.
 Many users are likely to run afoul of the fact that Spring Security's transitive dependencies resolve Spring Framework {spring-core-version}, which can cause strange classpath problems.
 The easiest way to resolve this is to use the `spring-framework-bom` within your `<dependencyManagement>` section of your `pom.xml`.
 You can do so by using the https://github.com/spring-gradle-plugins/dependency-management-plugin[Dependency Management Plugin], as the following example shows:

docs/manual/src/docs/asciidoc/_includes/about/samples.adoc

@@ -1,3 +1,4 @@
+[[samples]]
 = Samples
 
 Spring Security includes many {gh-samples-url}[samples] applications.

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

@@ -83,7 +83,7 @@ In order for the <<csrf-protection-stp,synchronizer token pattern>> to protect a
 This must be included in a part of the request (i.e. form parameter, HTTP header, etc) that is not automatically included in the HTTP request by the browser.
 
 Spring Security's https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/server/csrf/CsrfWebFilter.html[CsrfWebFilter] exposes a https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/csrf/CsrfToken.html[Mono<CsrfToken>] as a `ServerWebExchange` attribute named `org.springframework.security.web.server.csrf.CsrfToken`.
-This means that any view technology can access the `Mono<CsrfToken>` to expose the expected token as either a <<webflux-csrf-include-form-attr,form>> or <<webflux-csrf-include-ajax-meta-attr,meta tag>>.
+This means that any view technology can access the `Mono<CsrfToken>` to expose the expected token as either a <<webflux-csrf-include-form-attr,form>> or <<webflux-csrf-include-ajax-meta,meta tag>>.
 
 [[webflux-csrf-include-subscribe]]
 If your view technology does not provide a simple way to subscribe to the `Mono<CsrfToken>`, a common pattern is to use Spring's `@ControllerAdvice` to expose the `CsrfToken` directly.

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

@@ -54,4 +54,4 @@ Spring Security provides support for <<servlet-headers-hsts,Strict Transport Sec
 [[webflux-http-proxy-server]]
 == Proxy Server Configuration
 
-Spring Security <<http-proxy-servers,integrates with proxy servers>>.
+Spring Security <<http-proxy-server,integrates with proxy servers>>.

docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/login.adoc

@@ -38,11 +38,11 @@ The redirect URI is the path in the application that the end-user's user-agent i
 
 In the "Set a redirect URI" sub-section, ensure that the *Authorized redirect URIs* field is set to `http://localhost:8080/login/oauth2/code/google`.
 
-TIP: The default redirect URI template is `{baseUrl}/login/oauth2/code/{registrationId}`.
-The *_registrationId_* is a unique identifier for the <<jc-oauth2login-client-registration,ClientRegistration>>.
+TIP: The default redirect URI template is `+{baseUrl}/login/oauth2/code/{registrationId}+`.
+The *_registrationId_* is a unique identifier for the <<oauth2Client-client-registration,ClientRegistration>>.
 For our example, the `registrationId` is `google`.
 
-IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check <<appendix-proxy-server, Proxy Server Configuration>> to ensure the application is correctly configured.
+IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check <<http-proxy-server,Proxy Server Configuration>> to ensure the application is correctly configured.
 Also, see the supported <<oauth2Client-auth-code-redirect-uri, `URI` template variables>> for `redirect-uri`.
 
 [[webflux-oauth2-login-sample-config]]
@@ -68,7 +68,7 @@ spring:
 .OAuth Client properties
 ====
 <1> `spring.security.oauth2.client.registration` is the base property prefix for OAuth Client properties.
-<2> Following the base property prefix is the ID for the <<jc-oauth2login-client-registration,ClientRegistration>>, such as google.
+<2> Following the base property prefix is the ID for the <<oauth2Client-client-registration,ClientRegistration>>, such as google.
 ====
 
 . Replace the values in the `client-id` and `client-secret` property with the OAuth 2.0 credentials you created earlier.

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

@@ -117,7 +117,7 @@ We still specify the `issuer-uri` so that Resource Server still validates the `i
 [NOTE]
 This property can also be supplied directly on the <<webflux-oauth2resourceserver-jwt-jwkseturi-dsl,DSL>>.
 
-[[webflux-oauth2resourceserver-sansboot]]
+[[webflux-oauth2resourceserver-jwt-sansboot]]
 === Overriding or Replacing Boot Auto Configuration
 
 There are two `@Bean` s that Spring Boot generates on Resource Server's behalf.
@@ -559,6 +559,7 @@ This can be handy when revocation is a requirement.
 When using https://spring.io/projects/spring-boot[Spring Boot], configuring an application as a resource server that uses introspection consists of two basic steps.
 First, include the needed dependencies and second, indicate the introspection endpoint details.
 
+[[webflux-oauth2resourceserver-opaque-introspectionuri]]
 ==== Specifying the Authorization Server
 
 To specify where the introspection endpoint is, simply do:
@@ -1005,7 +1006,7 @@ ReactiveOpaqueTokenIntrospector introspector() {
 }
 ----
 
-[[oauth2resourceserver-multitenancy]]
+[[webflux-oauth2resourceserver-multitenancy]]
 == Multi-tenancy
 
 A resource server is considered multi-tenant when there are multiple strategies for verifying a bearer token, keyed by some tenant identifier.

docs/manual/src/docs/asciidoc/_includes/servlet/appendix/namespace.adoc

@@ -1248,7 +1248,7 @@ By default, an instance of `PortMapperImpl` will be added to the configuration f
 This element can optionally be used to override the default mappings which that class defines.
 Each child `<port-mapping>` element defines a pair of HTTP:HTTPS ports.
 The default mappings are 80:443 and 8080:8443.
-An example of overriding these can be found in the <<ns-requires-channel,namespace introduction>>.
+An example of overriding these can be found in <<servlet-http-redirect>>.
 
 
 [[nsa-port-mappings-parents]]
@@ -1751,7 +1751,7 @@ All elements which create `AuthenticationProvider` instances should be children
 [[nsa-authentication-manager-alias]]
 * **alias**
 This attribute allows you to define an alias name for the internal instance for use in your own configuration.
-Its use is described in the<<ns-auth-manager,namespace introduction>>.
+Its use is described in the <<ns-auth-manager,namespace introduction>>.
 
 
 [[nsa-authentication-manager-erase-credentials]]
@@ -1912,7 +1912,7 @@ select username, password, enabled from users where username = ?
 
 [[nsa-password-encoder]]
 ==== <password-encoder>
-Authentication providers can optionally be configured to use a password encoder as described in the <<ns-password-encoder,namespace introduction>>.
+Authentication providers can optionally be configured to use a password encoder as described in the <<authentication-password-storage>>.
 This will result in the bean being injected with the appropriate `PasswordEncoder` instance.
 
 
@@ -2338,7 +2338,7 @@ A method name
 
 [[nsa-ldap]]
 === LDAP Namespace Options
-LDAP is covered in some details in <<ldap,its own chapter>>.
+LDAP is covered in some details in <<servlet-authentication-ldap,its own chapter>>.
 We will expand on that here with some explanation of how the namespace options map to Spring beans.
 The LDAP implementation uses Spring LDAP extensively, so some familiarity with that project's API may be useful.
 
@@ -2348,7 +2348,7 @@ The LDAP implementation uses Spring LDAP extensively, so some familiarity with t
 `<ldap-server>` Element
 This element sets up a Spring LDAP `ContextSource` for use by the other LDAP beans, defining the location of the LDAP server and other information (such as a username and password, if it doesn't allow anonymous access) for connecting to it.
 It can also be used to create an embedded server for testing.
-Details of the syntax for both options are covered in the <<ldap-server,LDAP chapter>>.
+Details of the syntax for both options are covered in the <<servlet-authentication-ldap,LDAP chapter>>.
 The actual `ContextSource` implementation is `DefaultSpringSecurityContextSource` which extends Spring LDAP's `LdapContextSource` class.
 The `manager-dn` and `manager-password` attributes map to the latter's `userDn` and `password` properties respectively.
 
@@ -2443,7 +2443,7 @@ Defaults to "" (searching from the root).
 * **group-search-filter**
 Group search filter.
 Maps to the ``DefaultLdapAuthoritiesPopulator``'s `groupSearchFilter` property.
-Defaults to (uniqueMember={0}).
+Defaults to `+(uniqueMember={0})+`.
 The substituted parameter is the DN of the user.
 
 
@@ -2476,8 +2476,8 @@ If set, the framework will attempt to load standard attributes for the defined c
 * **user-dn-pattern**
 If your users are at a fixed location in the directory (i.e. you can work out the DN directly from the username without doing a directory search), you can use this attribute to map directly to the DN.
 It maps directly to the `userDnPatterns` property of `AbstractLdapAuthenticator`.
-The value is a specific pattern used to build the user's DN, for example "uid={0},ou=people".
-The key "{0}" must be present and will be substituted with the username.
+The value is a specific pattern used to build the user's DN, for example `+uid={0},ou=people+`.
+The key `+{0}+` must be present and will be substituted with the username.
 
 
 [[nsa-ldap-authentication-provider-user-search-base]]
@@ -2490,20 +2490,20 @@ Only used with a 'user-search-filter'.
 
 If you need to perform a search to locate the user in the directory, then you can set these attributes to control the search.
 The `BindAuthenticator` will be configured with a `FilterBasedLdapUserSearch` and the attribute values map directly to the first two arguments of that bean's constructor.
-If these attributes aren't set and no `user-dn-pattern` has been supplied as an alternative, then the default search values of `user-search-filter="(uid={0})"` and `user-search-base=""` will be used.
+If these attributes aren't set and no `user-dn-pattern` has been supplied as an alternative, then the default search values of `+user-search-filter="(uid={0})"+` and `user-search-base=""` will be used.
 
 
 [[nsa-ldap-authentication-provider-user-search-filter]]
 * **user-search-filter**
 The LDAP filter used to search for users (optional).
-For example "(uid={0})".
+For example `+(uid={0})+`.
 The substituted parameter is the user's login name.
 
 +
 
 If you need to perform a search to locate the user in the directory, then you can set these attributes to control the search.
 The `BindAuthenticator` will be configured with a `FilterBasedLdapUserSearch` and the attribute values map directly to the first two arguments of that bean's constructor.
-If these attributes aren't set and no `user-dn-pattern` has been supplied as an alternative, then the default search values of `user-search-filter="(uid={0})"` and `user-search-base=""` will be used.
+If these attributes aren't set and no `user-dn-pattern` has been supplied as an alternative, then the default search values of `+user-search-filter="(uid={0})"+` and `user-search-base=""` will be used.
 
 
 [[nsa-ldap-authentication-provider-children]]
@@ -2582,7 +2582,7 @@ Defaults to "" (searching from the root).
 [[nsa-ldap-user-service-group-search-filter]]
 * **group-search-filter**
 Group search filter.
-Defaults to (uniqueMember={0}).
+Defaults to `+(uniqueMember={0})+`.
 The substituted parameter is the DN of the user.
 
 
@@ -2625,5 +2625,5 @@ Only used with a 'user-search-filter'.
 [[nsa-ldap-user-service-user-search-filter]]
 * **user-search-filter**
 The LDAP filter used to search for users (optional).
-For example "(uid={0})".
+For example `+(uid={0})+`.
 The substituted parameter is the user's login name.

docs/manual/src/docs/asciidoc/_includes/servlet/architecture/core-services.adoc

@@ -79,7 +79,7 @@ Configuring the provider is quite simple:
 
 The `PasswordEncoder` is optional.
 A `PasswordEncoder` provides encoding and matching of encoded passwords presented in the `UserDetails` object that is returned from the configured `UserDetailsService`.
-This will be discussed in more detail <<core-services-password-encoding,below>>.
+This is discussed in more detail in <<authentication-password-storage>>.
 
 
 === UserDetailsService Implementations
@@ -105,7 +105,7 @@ Is easy to use create a custom `UserDetailsService` implementation that extracts
 This is particularly true if you're building a prototype application or just starting integrating Spring Security, when you don't really want to spend time configuring databases or writing `UserDetailsService` implementations.
 For this sort of situation, a simple option is to use the `user-service` element from the security <<ns-minimal,namespace>>:
 
-[source,xml]
+[source,xml,attrs="-attributes"]
 ----
 <user-service id="userDetailsService">
 <!-- Password is prefixed with {noop} to indicate to DelegatingPasswordEncoder that

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

@@ -168,4 +168,8 @@ Below is a comprehensive list of Spring Security Filter ordering:
 
 include::technical-overview.adoc[]
 
+include::security-filter-chain.adoc[]
+
+include::core-filters.adoc[]
+
 include::core-services.adoc[]

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/authentication-provider.adoc

@@ -19,7 +19,7 @@ public SpringAuthenticationProvider springAuthenticationProvider() {
 === AuthenticationProvider XML Configuration
 In practice you will need a more scalable source of user information than a few names added to the application context file.
 Most likely you will want to store your user information in something like a database or an LDAP server.
-LDAP namespace configuration is dealt with in the <<ldap,LDAP chapter>>, so we won't cover it here.
+LDAP namespace configuration is dealt with in the <<servlet-authentication-ldap,LDAP chapter>>, so we won't cover it here.
 If you have a custom implementation of Spring Security's `UserDetailsService`, called "myUserDetailsService" in your application context, then you can authenticate against this using
 
 [source,xml]

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

@@ -92,7 +92,7 @@ The web application side of CAS is made easy due to Spring Security.
 It is assumed you already know the basics of using Spring Security, so these are not covered again below.
 We'll assume a namespace based configuration is being used and add in the CAS beans as required.
 Each section builds upon the previous section.
-A full<<cas-sample,CAS sample application>> can be found in the Spring Security Samples.
+A full CAS sample application can be found in the Spring Security <<samples,Samples>>.
 
 
 [[cas-st]]
@@ -148,7 +148,7 @@ You can use these properties to customize things like behavior for authenticatio
 
 Next you need to add a `CasAuthenticationProvider` and its collaborators:
 
-[source,xml]
+[source,xml,attrs="-attributes"]
 ----
 <security:authentication-manager alias="authenticationManager">
 <security:authentication-provider ref="casAuthenticationProvider" />
@@ -337,7 +337,7 @@ An example configuration is shown below.
 [[cas-pt-client-sample]]
 ===== Calling a Stateless Service Using a Proxy Ticket
 Now that Spring Security obtains PGTs, you can use them to create proxy tickets which can be used to authenticate to a stateless service.
-The <<cas-sample,CAS sample application>> contains a working example in the `ProxyTicketSampleServlet`.
+The CAS <<samples,sample application>> contains a working example in the `ProxyTicketSampleServlet`.
 Example code can be found below:
 
 [source,java]

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

@@ -1,5 +1,4 @@
 [[session-mgmt]]
-[[ns-session-mgmt]]
 == Session Management
 HTTP session related functionality is handled by a combination of the `SessionManagementFilter` and the `SessionAuthenticationStrategy` interface, which the filter delegates to.
 Typical usage includes session-fixation protection attack prevention, detection of session timeouts and restrictions on how many sessions an authenticated user may have open concurrently.
@@ -126,7 +125,7 @@ It will then invoke the configured `SessionAuthenticationStrategy`.
 
 If the user is not currently authenticated, the filter will check whether an invalid session ID has been requested (because of a timeout, for example) and will invoke the configured `InvalidSessionStrategy`, if one is set.
 The most common behaviour is just to redirect to a fixed URL and this is encapsulated in the standard implementation `SimpleRedirectInvalidSessionStrategy`.
-The latter is also used when configuring an invalid session URL through the namespace,<<ns-session-mgmt,as described earlier>>.
+The latter is also used when configuring an invalid session URL through the namespace,<<session-mgmt,as described earlier>>.
 
 
 === SessionAuthenticationStrategy

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/storage/in-memory.adoc

@@ -5,12 +5,12 @@ Spring Security's `InMemoryUserDetailsManager` implements <<servlet-authenticati
 `InMemoryUserDetailsManager` provides management of `UserDetails` by implementing the `UserDetailsManager` interface.
 `UserDetails` based authentication is used by Spring Security when it is configured to <<servlet-authentication-unpwd-input,accept a username/password>> for authentication.
 
-In this sample we use <<authentication-password-storage-boot-cli,Spring Boot CLI>> to encode the password of `password` and get the encoded password of `{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW`.
+In this sample we use <<authentication-password-storage-boot-cli,Spring Boot CLI>> to encode the password of `password` and get the encoded password of `+{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW+`.
 
 .InMemoryUserDetailsManager Java Configuration
 ====
 .Java
-[source,java,role="primary"]
+[source,java,role="primary",attrs="-attributes"]
 ----
 @Bean
 public UserDetailsService users() {
@@ -29,7 +29,7 @@ public UserDetailsService users() {
 ----
 
 .XML
-[source,xml,role="secondary"]
+[source,xml,role="secondary",attrs="-attributes"]
 ----
 <user-service>
 	<user name="user"
@@ -42,7 +42,7 @@ public UserDetailsService users() {
 ----
 
 .Kotlin
-[source,kotlin,role="secondary"]
+[source,kotlin,role="secondary,attrs="-attributes""]
 ----
 @Bean
 fun users(): UserDetailsService {
@@ -114,11 +114,11 @@ fun users(): UserDetailsService {
 ====
 
 There is no simple way to use `User.withDefaultPasswordEncoder` with XML based configuration.
-For demos or just getting started, you can choose to prefix the password with `{noop}` to indicate <<authentication-password-storage-dpe-format,no encoding should be used>>.
+For demos or just getting started, you can choose to prefix the password with `+{noop}+` to indicate <<authentication-password-storage-dpe-format,no encoding should be used>>.
 
-.<user-service> `{noop}` XML Configuration
+.<user-service> `+{noop}+` XML Configuration
 ====
-[source,xml]
+[source,xml,attrs="-attributes"]
 ----
 <user-service>
 	<user name="user"

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/storage/jdbc.adoc

@@ -147,14 +147,14 @@ In a production environment, you will want to ensure you setup a connection to a
 [[servlet-authentication-jdbc-bean]]
 == JdbcUserDetailsManager Bean
 
-In this sample we use <<authentication-password-storage-boot-cli,Spring Boot CLI>> to encode the password of `password` and get the encoded password of `{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW`.
+In this sample we use <<authentication-password-storage-boot-cli,Spring Boot CLI>> to encode the password of `password` and get the encoded password of `+{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW+`.
 See the <<authentication-password-storage,PasswordEncoder>> section for more details about how to store passwords.
 
 .JdbcUserDetailsManager
 ====
 
 .Java
-[source,java,role="primary"]
+[source,java,role="primary",attrs="-attributes"]
 ----
 @Bean
 UserDetailsManager users(DataSource dataSource) {
@@ -174,7 +174,7 @@ UserDetailsManager users(DataSource dataSource) {
 ----
 
 .XML
-[source,xml,role="secondary"]
+[source,xml,role="secondary",attrs="-attributes"]
 ----
 <jdbc-user-service>
 	<user name="user"
@@ -187,7 +187,7 @@ UserDetailsManager users(DataSource dataSource) {
 ----
 
 .Kotlin
-[source,kotlin,role="secondary"]
+[source,kotlin,role="secondary",attrs="-attributes"]
 ----
 @Bean
 fun users(dataSource: DataSource): UserDetailsManager {

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/storage/ldap.adoc

@@ -284,7 +284,7 @@ An example of bind authentication configuration can be found below.
 .Bind Authentication
 ====
 .Java
-[source,java,role="primary"]
+[source,java,role="primary",attrs="-attributes"]
 ----
 @Bean
 BindAuthenticator authenticator(BaseLdapPathContextSource contextSource) {
@@ -300,14 +300,14 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
 ----
 
 .XML
-[source,xml,role="secondary"]
+[source,xml,role="secondary",attrs="-attributes"]
 ----
 <ldap-authentication-provider
 	user-dn-pattern="uid={0},ou=people"/>
 ----
 
 .Kotlin
-[source,kotlin,role="secondary"]
+[source,kotlin,role="secondary",attrs="-attributes"]
 ----
 @Bean
 fun authenticator(contextSource: BaseLdapPathContextSource): BindAuthenticator {
@@ -330,7 +330,7 @@ If instead you wished to configure an LDAP search filter to locate the user, you
 .Bind Authentication with Search Filter
 ====
 .Java
-[source,java,role="primary"]
+[source,java,role="primary",attrs="-attributes"]
 ----
 @Bean
 BindAuthenticator authenticator(BaseLdapPathContextSource contextSource) {
@@ -350,7 +350,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
 ----
 
 .XML
-[source,xml,role="secondary"]
+[source,xml,role="secondary",attrs="-attributes"]
 ----
 <ldap-authentication-provider
 		user-search-filter="(uid={0})"
@@ -358,7 +358,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
 ----
 
 .Kotlin
-[source,kotlin,role="secondary"]
+[source,kotlin,role="secondary",attrs="-attributes"]
 ----
 @Bean
 fun authenticator(contextSource: BaseLdapPathContextSource): BindAuthenticator {
@@ -377,7 +377,7 @@ fun authenticationProvider(authenticator: LdapAuthenticator): LdapAuthentication
 ----
 ====
 
-If used with the `ContextSource` <<servlet-authentication-ldap-contextsource,definition above>>, this would perform a search under the DN `ou=people,dc=springframework,dc=org` using `(uid={0})` as a filter.
+If used with the `ContextSource` <<servlet-authentication-ldap-contextsource,definition above>>, this would perform a search under the DN `ou=people,dc=springframework,dc=org` using `+(uid={0})+` as a filter.
 Again the user login name is substituted for the parameter in the filter name, so it will search for an entry with the `uid` attribute equal to the user name.
 If a user search base isn't supplied, the search will be performed from the root.
 
@@ -405,7 +405,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
 ----
 
 .XML
-[source,xml,role="secondary"]
+[source,xml,role="secondary",attrs="-attributes"]
 ----
 <ldap-authentication-provider
 		user-dn-pattern="uid={0},ou=people">
@@ -451,7 +451,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
 ----
 
 .XML
-[source,xml,role="secondary"]
+[source,xml,role="secondary",attrs="-attributes"]
 ----
 <ldap-authentication-provider
 		user-dn-pattern="uid={0},ou=people">
@@ -492,7 +492,7 @@ Spring Security's `LdapAuthoritiesPopulator` is used to determine what authorite
 .Minimal Password Compare Configuration
 ====
 .Java
-[source,java,role="primary"]
+[source,java,role="primary",attrs="-attributes"]
 ----
 @Bean
 LdapAuthoritiesPopulator authorities(BaseLdapPathContextSource contextSource) {
@@ -510,7 +510,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
 ----
 
 .XML
-[source,xml,role="secondary"]
+[source,xml,role="secondary",attrs="-attributes"]
 ----
 <ldap-authentication-provider
 	user-dn-pattern="uid={0},ou=people"
@@ -518,7 +518,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
 ----
 
 .Kotlin
-[source,kotlin,role="secondary"]
+[source,kotlin,role="secondary",attrs="-attributes"]
 ----
 @Bean
 fun authorities(contextSource: BaseLdapPathContextSource): LdapAuthoritiesPopulator {

docs/manual/src/docs/asciidoc/_includes/servlet/authorization/expression-based.adoc

@@ -150,7 +150,7 @@ http
 ==== Path Variables in Web Security Expressions
 
 At times it is nice to be able to refer to path variables within a URL.
-For example, consider a RESTful application that looks up a user by id from the URL path in the format `/user/{userId}`.
+For example, consider a RESTful application that looks up a user by id from the URL path in the format `+/user/{userId}+`.
 
 You can easily refer to the path variable by placing it in the pattern.
 For example, if you had a Bean with the name of `webSecurity` that contains the following method signature:
@@ -166,7 +166,7 @@ public class WebSecurity {
 
 You could refer to the method using:
 
-[source,xml]
+[source,xml,attrs="-attributes"]
 ----
 <http>
 	<intercept-url pattern="/user/{userId}/**"
@@ -177,7 +177,7 @@ You could refer to the method using:
 
 or in Java configuration
 
-[source,java]
+[source,java,attrs="-attributes"]
 ----
 http
 	.authorizeRequests(authorize -> authorize

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

@@ -55,4 +55,4 @@ Spring Security provides support for <<servlet-headers-hsts,Strict Transport Sec
 [[servlet-http-proxy-server]]
 == Proxy Server Configuration
 
-Spring Security <<http-proxy-servers,integrates with proxy servers>>.
+Spring Security <<http-proxy-server,integrates with proxy servers>>.

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

@@ -18,7 +18,7 @@ For example, adding the following element from the security namespace to an appl
 
 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 `ldap-server` element and the user is isolated from worrying about which beans they need to create and what the bean property names are.
-footnote:[You can find out more about the use of the `ldap-server` element in the chapter on pass:specialcharacters,macros[<<ldap>>].].
+footnote:[You can find out more about the use of the `ldap-server` element in the chapter on pass:specialcharacters,macros[<<servlet-authentication-ldap>>].].
 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 https://spring.io/tools/sts[Spring Tool Suite] as it has special features for working with standard Spring namespaces.
 
@@ -148,7 +148,7 @@ You can also add a `method` attribute to limit the match to a particular HTTP me
 
 To add some users, you can define a set of test data directly in the namespace:
 
-[source,xml]
+[source,xml,attrs="-attributes"]
 ----
 <authentication-manager>
 <authentication-provider>
@@ -164,9 +164,9 @@ To add some users, you can define a set of test data directly in the namespace:
 ----
 
 This is an example of a secure way of storing the same passwords.
-The password is prefixed with `{bcrypt}` to instruct `DelegatingPasswordEncoder`, which supports any configured `PasswordEncoder` for matching, that the passwords are hashed using BCrypt:
+The password is prefixed with `+{bcrypt}+` to instruct `DelegatingPasswordEncoder`, which supports any configured `PasswordEncoder` for matching, that the passwords are hashed using BCrypt:
 
-[source,xml]
+[source,xml,attrs="-attributes"]
 ----
 <authentication-manager>
 <authentication-provider>

docs/manual/src/docs/asciidoc/_includes/servlet/oauth2/oauth2-client.adoc

@@ -364,11 +364,11 @@ Please refer to the https://tools.ietf.org/html/rfc6749#section-4.1.1[Authorizat
 The `OAuth2AuthorizationRequestRedirectFilter` uses an `OAuth2AuthorizationRequestResolver` to resolve an `OAuth2AuthorizationRequest` and initiate the Authorization Code grant flow by redirecting the end-user's user-agent to the Authorization Server's Authorization Endpoint.
 
 The primary role of the `OAuth2AuthorizationRequestResolver` is to resolve an `OAuth2AuthorizationRequest` from the provided web request.
-The default implementation `DefaultOAuth2AuthorizationRequestResolver` matches on the (default) path `/oauth2/authorization/{registrationId}` extracting the `registrationId` and using it to build the `OAuth2AuthorizationRequest` for the associated `ClientRegistration`.
+The default implementation `DefaultOAuth2AuthorizationRequestResolver` matches on the (default) path `+/oauth2/authorization/{registrationId}+` extracting the `registrationId` and using it to build the `OAuth2AuthorizationRequest` for the associated `ClientRegistration`.
 
 Given the following Spring Boot 2.x properties for an OAuth 2.0 Client registration:
 
-[source,yaml]
+[source,yaml,attrs="-attributes"]
 ----
 spring:
   security:
@@ -395,7 +395,7 @@ which also initiates the Authorization Request redirect by the `OAuth2Authorizat
 
 If the OAuth 2.0 Client is a https://tools.ietf.org/html/rfc6749#section-2.1[Public Client], then configure the OAuth 2.0 Client registration as follows:
 
-[source,yaml]
+[source,yaml,attrs="-attributes"]
 ----
 spring:
   security:
@@ -421,7 +421,7 @@ The `DefaultOAuth2AuthorizationRequestResolver` also supports `URI` template var
 
 The following configuration uses all the supported `URI` template variables:
 
-[source,yaml]
+[source,yaml,attrs="-attributes"]
 ----
 spring:
   security:
@@ -435,9 +435,9 @@ spring:
 ----
 
 [NOTE]
-`{baseUrl}` resolves to `{baseScheme}://{baseHost}{basePort}{basePath}`
+`+{baseUrl}+` resolves to `+{baseScheme}://{baseHost}{basePort}{basePath}+`
 
-Configuring the `redirect-uri` with `URI` template variables is especially useful when the OAuth 2.0 Client is running behind a <<appendix-proxy-server, Proxy Server>>.
+Configuring the `redirect-uri` with `URI` template variables is especially useful when the OAuth 2.0 Client is running behind a <<http-proxy-server,Proxy Server>>.
 This ensures that the `X-Forwarded-*` headers are used when expanding the `redirect-uri`.
 
 ===== Customizing the Authorization Request

docs/manual/src/docs/asciidoc/_includes/servlet/oauth2/oauth2-login.adoc

@@ -39,10 +39,10 @@ The redirect URI is the path in the application that the end-user's user-agent i
 
 In the "Set a redirect URI" sub-section, ensure that the *Authorized redirect URIs* field is set to `http://localhost:8080/login/oauth2/code/google`.
 
-TIP: The default redirect URI template is `{baseUrl}/login/oauth2/code/{registrationId}`.
+TIP: The default redirect URI template is `+{baseUrl}/login/oauth2/code/{registrationId}+`.
 The *_registrationId_* is a unique identifier for the <<oauth2Client-client-registration,ClientRegistration>>.
 
-IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check <<appendix-proxy-server, Proxy Server Configuration>> to ensure the application is correctly configured.
+IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check <<http-proxy-server,Proxy Server Configuration>> to ensure the application is correctly configured.
 Also, see the supported <<oauth2Client-auth-code-redirect-uri, `URI` template variables>> for `redirect-uri`.
 
 
@@ -248,7 +248,7 @@ If you need to override the auto-configuration based on your specific requiremen
 
 The following example shows how to register a `ClientRegistrationRepository` `@Bean`:
 
-[source,java]
+[source,java,attrs="-attributes"]
 ----
 @Configuration
 public class OAuth2LoginConfig {
@@ -305,7 +305,7 @@ public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {
 
 The following example shows how to completely override the auto-configuration by registering a `ClientRegistrationRepository` `@Bean` and providing a `WebSecurityConfigurerAdapter`.
 
-[source,java]
+[source,java,attrs="-attributes"]
 ----
 @Configuration
 public class OAuth2LoginConfig {
@@ -508,7 +508,7 @@ See `InMemoryClientRegistrationRepository` for reference.
 
 The link's destination for each OAuth Client defaults to the following:
 
-`OAuth2AuthorizationRequestRedirectFilter.DEFAULT_AUTHORIZATION_REQUEST_BASE_URI` + "/{registrationId}"
+`+OAuth2AuthorizationRequestRedirectFilter.DEFAULT_AUTHORIZATION_REQUEST_BASE_URI + "/{registrationId}"+`
 
 The following line shows an example:
 
@@ -595,7 +595,7 @@ You also need to ensure the `ClientRegistration.redirectUriTemplate` matches the
 
 The following listing shows an example:
 
-[source,java]
+[source,java,attrs="-attributes"]
 ----
 return CommonOAuth2Provider.GOOGLE.getBuilder("google")
 	.clientId("google-client-id")

docs/manual/src/docs/asciidoc/_includes/servlet/oauth2/oauth2-resourceserver.adoc

@@ -709,6 +709,7 @@ This can be handy when revocation is a requirement.
 When using https://spring.io/projects/spring-boot[Spring Boot], configuring an application as a resource server that uses introspection consists of two basic steps.
 First, include the needed dependencies and second, indicate the introspection endpoint details.
 
+[[oauth2resourceserver-opaque-introspectionuri]]
 ==== Specifying the Authorization Server
 
 To specify where the introspection endpoint is, simply do:

docs/manual/src/docs/asciidoc/_includes/servlet/saml2/saml2-login.adoc

@@ -46,8 +46,8 @@ the IDP sends an assertion to the SP.
 [[samllogin-feature-set]]
 === Saml 2 Login - Current Feature Set
 
-1. Service Provider (SP/Relying Party) is identified by `entityId = {baseUrl}/saml2/service-provider-metadata/{registrationId}`
-2. Receive assertion embedded in a SAML response via Http-POST or Http-Redirect at `{baseUrl}/login/saml2/sso/{registrationId}`
+1. Service Provider (SP/Relying Party) is identified by `+entityId = {baseUrl}/saml2/service-provider-metadata/{registrationId}+`
+2. Receive assertion embedded in a SAML response via Http-POST or Http-Redirect at `+{baseUrl}/login/saml2/sso/{registrationId}+`
 3. Requires the assertion to be signed, unless the response is signed
 4. Supports encrypted assertions
 5. Supports encrypted NameId elements
@@ -131,9 +131,7 @@ an incoming request. The URI patterns in `saml2Login` can contain the following
 * `basePort`
 
 For example:
-```
-{baseUrl}/login/saml2/sso/{registrationId}
-```
+`+{baseUrl}/login/saml2/sso/{registrationId}+`
 
 ===== Relying Party
 
@@ -141,7 +139,7 @@ For example:
 * `registrationId` - (required) a unique identifer for this configuration mapping.
 This identifier may be used in URI paths, so care should be taken that no URI encoding is required.
 * `localEntityIdTemplate` - (optional) A URI pattern that creates an entity ID for this application based on the incoming request. The default is
-`{baseUrl}/saml2/service-provider-metadata/{registrationId}` and for a small sample application
+`+{baseUrl}/saml2/service-provider-metadata/{registrationId}+` and for a small sample application
 it would look like
 ```
 http://localhost:8080/saml2/service-provider-metadata/my-test-configuration
@@ -153,7 +151,7 @@ no patterns allowed.
 * `assertionConsumerServiceUrlTemplate` - (optional) A URI pattern that denotes the assertion
 consumer service URI to be sent with any `AuthNRequest` from the SP to the IDP during the SP initiated flow.
 While this can be a pattern the actual URI must resolve to the ACS endpoint on the SP.
-The default value is `{baseUrl}/login/saml2/sso/{registrationId}` and maps directly to the
+The default value is `+{baseUrl}/login/saml2/sso/{registrationId}+` and maps directly to the
 https://github.com/spring-projects/spring-security/blob/5.2.0.RELEASE/saml2/saml2-service-provider/src/main/java/org/springframework/security/saml2/provider/service/servlet/filter/Saml2WebSsoAuthenticationFilter.java#L42[`Saml2WebSsoAuthenticationFilter`] endpoint
 * `idpWebSsoUrl`  - (required) a fixed URI value for the IDP Single Sign On endpoint where
 the SP sends the `AuthNRequest` messages.
@@ -198,10 +196,10 @@ credentials on all the identity providers.
 The Spring Security SAML 2 implementation does not yet provide an endpoint for downloading
 SP metadata in XML format. The minimal pieces that are exchanged
 
-* *entity ID* - defaults to `{baseUrl}/saml2/service-provider-metadata/{registrationId}`
+* *entity ID* - defaults to `+{baseUrl}/saml2/service-provider-metadata/{registrationId}+`
 Other known configuration names that also use this same value
 ** Audience Restriction
-* *single signon URL* - defaults to `{baseUrl}/login/saml2/sso/{registrationId}`
+* *single signon URL* - defaults to `+{baseUrl}/login/saml2/sso/{registrationId}+`
 Other known configuration names that also use this same value
 ** Recipient URL
 ** Destination URL
@@ -212,9 +210,9 @@ credentials must be shared with the Identity Provider
 ==== Authentication Requests - SP Initiated Flow
 
 To initiate an authentication from the web application, a simple redirect to
-```
-{baseUrl}/saml2/authenticate/{registrationId}
-```
+
+`+{baseUrl}/saml2/authenticate/{registrationId}+`
+
 The endpoint will generate an `AuthNRequest` by invoking the `createAuthenticationRequest` method on a
 configurable factory. Just expose the `Saml2AuthenticationRequestFactory` as a bean in your configuration.
 [source,java]
@@ -345,9 +343,7 @@ To run the sample, follow these three steps
 It's very simple to use multiple providers, but there are some defaults that
 may trip you up if you don't pay attention. In our SAML configuration of
 `RelyingPartyRegistration` objects, we default an SP entity ID to
-```
-{baseUrl}/saml2/service-provider-metadata/{registrationId}
-```
+`+{baseUrl}/saml2/service-provider-metadata/{registrationId}+`
 
 That means in our two provider configuration, our system would look like
 
@@ -401,12 +397,15 @@ spring:
 ----
 
 If this is not desirable, you can manually override the local SP entity ID by using the
-```
+
+[source,attrs="-attributes"]
+----
 localEntityIdTemplate = {baseUrl}/saml2/service-provider-metadata
-```
+----
+
 If we change our local SP entity ID to this value, it is still important that we give
 out the correct single sign on URL (the assertion consumer service URL)
 for each registered identity provider based on the registration Id.
-`{baseUrl}/login/saml2/sso/{registrationId}`
+`+{baseUrl}/login/saml2/sso/{registrationId}+`