From 04b6096d19e6329e5ec4d2e40fdee2b310d58704 Mon Sep 17 00:00:00 2001 From: Rob Winch Date: Wed, 8 Jan 2020 21:59:14 -0600 Subject: [PATCH] Fix Asciidoctor Warnings Issue gh-7801 --- .../reactive/oauth2/resource-server.adoc | 4 ++-- .../asciidoc/_includes/reactive/test.adoc | 4 ++-- .../servlet/appendix/database-schema.adoc | 24 +++++++++---------- .../_includes/servlet/namespace/index.adoc | 6 ++--- 4 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/resource-server.adoc b/docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/resource-server.adoc index 25a3060d05..4379732e40 100644 --- a/docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/resource-server.adoc +++ b/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 <> or <>. [[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`: diff --git a/docs/manual/src/docs/asciidoc/_includes/reactive/test.adoc b/docs/manual/src/docs/asciidoc/_includes/reactive/test.adoc index bbd1241150..1be03d22b8 100644 --- a/docs/manual/src/docs/asciidoc/_includes/reactive/test.adoc +++ b/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: diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/appendix/database-schema.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/appendix/database-schema.adoc index e21a6147c0..7353d783aa 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/appendix/database-schema.adoc +++ b/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 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 <> 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 ( diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/namespace/index.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/namespace/index.adoc index d28c7793b4..5b30c3c259 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/namespace/index.adoc +++ b/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 <> which is used.]. -In Spring Security 3.0, the attribute can also be populated with an pass:specialcharacters,macros[<>]. +In Spring Security 3.0, the attribute can also be populated with an <>. [NOTE] -=== +==== You can use multiple `` 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: