Fix Asciidoctor Warnings

Issue gh-7801

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

@@ -255,7 +255,7 @@ By default, `NimbusReactiveJwtDecoder`, and hence Resource Server, will only tru
 You can customize this via <<webflux-oauth2resourceserver-jwt-boot-algorithm,Spring Boot>> or <<webflux-oauth2resourceserver-jwt-decoder-builder,the NimbusJwtDecoder builder>>.
 
 [[webflux-oauth2resourceserver-jwt-boot-algorithm]]
-==== Via Spring Boot
+=== Via Spring Boot
 
 The simplest way to set the algorithm is as a property:
 
@@ -271,7 +271,7 @@ spring:
 ----
 
 [[webflux-oauth2resourceserver-jwt-decoder-builder]]
-==== Using a Builder
+=== Using a Builder
 
 For greater power, though, we can use a builder that ships with `NimbusReactiveJwtDecoder`:
 

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

@@ -159,7 +159,7 @@ All of this can be quite daunting, especially when this isn't the focus of your
 Fortunately, there are a number of simple ways that you can overcome this difficulty and allow your tests to focus on authorization and not on representing bearer tokens.
 We'll look at two of them now:
 
-===== `mockJwt() WebTestClientConfigurer`
+==== `mockJwt() WebTestClientConfigurer`
 
 The first way is via a `WebTestClientConfigurer`.
 The simplest of these would look something like this:
@@ -248,7 +248,7 @@ client
 	.get().uri("/endpoint").exchange();
 ----
 
-===== `authentication()` `WebTestClientConfigurer`
+==== `authentication()` `WebTestClientConfigurer`
 
 The second way is by using the `authentication()` `Mutator`.
 Essentially, you can instantiate your own `JwtAuthenticationToken` and provide it in your test, like so:

docs/manual/src/docs/asciidoc/_includes/servlet/appendix/database-schema.adoc

@@ -1,5 +1,5 @@
-__[[__appendix-schema]]
-== Security Database Schema
+[[__appendix-schema]]
+= Security Database Schema
 There are various database schema used by the framework and this appendix provides a single reference point to them all.
 You only need to provide the tables for the areas of functionality you require.
 
@@ -7,7 +7,7 @@ DDL statements are given for the HSQLDB database.
 You can use these as a guideline for defining the schema for the database you are using.
 
 
-=== User Schema
+== User Schema
 The standard JDBC implementation of the `UserDetailsService` (`JdbcDaoImpl`) requires tables to load the password, account status (enabled or disabled) and a list of authorities (roles) for the user.
 You will need to adjust this schema to match the database dialect you are using.
 
@@ -28,7 +28,7 @@ create table authorities (
 create unique index ix_auth_username on authorities (username,authority);
 ----
 
-==== For Oracle database
+=== For Oracle database
 [source]
 ----
 CREATE TABLE USERS (
@@ -46,7 +46,7 @@ ALTER TABLE AUTHORITIES ADD CONSTRAINT AUTHORITIES_UNIQUE UNIQUE (USERNAME, AUTH
 ALTER TABLE AUTHORITIES ADD CONSTRAINT AUTHORITIES_FK1 FOREIGN KEY (USERNAME) REFERENCES USERS (USERNAME) ENABLE;
 ----
 
-==== Group Authorities
+=== Group Authorities
 Spring Security 2.0 introduced support for group authorities in `JdbcDaoImpl`.
 The table structure if groups are enabled is as follows.
 You will need to adjust this schema to match the database dialect you are using.
@@ -77,7 +77,7 @@ Remember that these tables are only required if you are using the provided JDBC
 If you write your own or choose to implement `AuthenticationProvider` without a `UserDetailsService`, then you have complete freedom over how you store the data, as long as the interface contract is satisfied.
 
 
-=== Persistent Login (Remember-Me) Schema
+== Persistent Login (Remember-Me) Schema
 This table is used to store data used by the more secure <<remember-me-persistent-token,persistent token>> remember-me implementation.
 If you are using `JdbcTokenRepositoryImpl` either directly or through the namespace, then you will need this table.
 Remember to adjust this schema to match the database dialect you are using.
@@ -95,7 +95,7 @@ create table persistent_logins (
 ----
 
 [[dbschema-acl]]
-=== ACL Schema
+== ACL Schema
 There are four tables used by the Spring Security <<domain-acls,ACL>> implementation.
 
 . `acl_sid` stores the security identities recognised by the ACL system.
@@ -113,7 +113,7 @@ Both of these default to `call identity()`
 The ACL artifact JAR contains files for creating the ACL schema in HyperSQL (HSQLDB), PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, and Oracle Database.
 These schemas are also demonstrated in the following sections.
 
-==== HyperSQL
+=== HyperSQL
 The default schema works with the embedded HSQLDB database that is used in unit tests within the framework.
 
 [source,ddl]
@@ -160,7 +160,7 @@ create table acl_entry(
 );
 ----
 
-==== PostgreSQL
+=== PostgreSQL
 [source,ddl]
 ----
 create table acl_sid(
@@ -209,7 +209,7 @@ You will have to set the `classIdentityQuery` and `sidIdentityQuery` properties
 * `select currval(pg_get_serial_sequence('acl_class', 'id'))`
 * `select currval(pg_get_serial_sequence('acl_sid', 'id'))`
 
-==== MySQL and MariaDB
+=== MySQL and MariaDB
 [source,ddl]
 ----
 CREATE TABLE acl_sid (
@@ -253,7 +253,7 @@ CREATE TABLE acl_entry (
 ) ENGINE=InnoDB;
 ----
 
-==== Microsoft SQL Server
+=== Microsoft SQL Server
 [source,ddl]
 ----
 CREATE TABLE acl_sid (
@@ -297,7 +297,7 @@ CREATE TABLE acl_entry (
 );
 ----
 
-==== Oracle Database
+=== Oracle Database
 [source,ddl]
 ----
 CREATE TABLE ACL_SID (

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

@@ -134,17 +134,17 @@ The prefix "ROLE_" is a marker which indicates that a simple comparison with the
 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:[The interpretation of the comma-separated values in the `access` attribute depends on the implementation of the <<ns-access-manager,AccessDecisionManager>> which is used.].
-In Spring Security 3.0, the attribute can also be populated with an pass:specialcharacters,macros[<<el-access,EL expression>>].
+In Spring Security 3.0, the attribute can also be populated with an <<el-access,EL expression>>.
 
 
 [NOTE]
-===
+====
 
 You can use multiple `<intercept-url>` elements to define different access requirements for different sets of URLs, but they will be evaluated in the order listed and the first match will be used.
 So you must put the most specific matches at the top.
 You can also add a `method` attribute to limit the match to a particular HTTP method (`GET`, `POST`, `PUT` etc.).
 
-===
+====
 
 To add some users, you can define a set of test data directly in the namespace: