From 24cd9b990a9b534b76b4d4dd61aa846fe3a46f10 Mon Sep 17 00:00:00 2001 From: Angel Aguilera Date: Fri, 23 Aug 2019 16:11:10 +0200 Subject: [PATCH] fix footnotes markup Fixes #3180 --- .../_includes/servlet/architecture/technical-overview.adoc | 2 +- .../src/docs/asciidoc/_includes/servlet/preface/namespace.adoc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc index 7cf910c672..de0cedb91e 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc @@ -258,7 +258,7 @@ Or you might work for a company that has a legacy proprietary authentication sys In situations like this it's quite easy to get Spring Security to work, and still provide authorization capabilities. All you need to do is write a filter (or equivalent) that reads the third-party user information from a location, build a Spring Security-specific `Authentication` object, and put it into the `SecurityContextHolder`. In this case you also need to think about things which are normally taken care of automatically by the built-in authentication infrastructure. -For example, you might need to pre-emptively create an HTTP session to <>, before you write the response to the client footnote:[It isn't possible to create a session once the response has been committed. +For example, you might need to pre-emptively create an HTTP session to <>, before you write the response to the client footnote:[It isn't possible to create a session once the response has been committed.]. If you're wondering how the `AuthenticationManager` is implemented in a real world example, we'll look at that in the <>. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/preface/namespace.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/preface/namespace.adoc index ff49f69556..30508f8a86 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/preface/namespace.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/preface/namespace.adoc @@ -133,7 +133,7 @@ With the default configuration, this is typically a comma-separated list of role The prefix "ROLE_" is a marker which indicates that a simple comparison with the user's authorities should be made. 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 pass:specialcharacters,macros[<>] which is used. +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 pass:specialcharacters,macros[<>] which is used.]. In Spring Security 3.0, the attribute can also be populated with an pass:specialcharacters,macros[<>].