Merge branch '7.0.x'

docs/modules/ROOT/pages/servlet/authentication/logout.adoc

@@ -81,6 +81,12 @@ Xml::
 
 and no authorization changes are necessary since it simply adjusts the `LogoutFilter`.
 
+[NOTE]
+====
+The URI passed to `logoutUrl` (and to `logoutSuccessUrl`) is matched and redirected to literally.
+If you want either URI to live under your application servlet's base path, include that prefix explicitly — for example, `logoutUrl("/api/logout")`.
+====
+
 [[permit-logout-endpoints]]
 However, if you stand up your own logout success endpoint (or in a rare case, <<creating-custom-logout-endpoint, your own logout endpoint>>), say using {spring-framework-reference-url}web.html#spring-web[Spring MVC], you will need to permit it in Spring Security.
 This is because Spring MVC processes your request after Spring Security does.

docs/modules/ROOT/pages/servlet/authentication/onetimetoken.adoc

@@ -252,6 +252,13 @@ class MagicLinkOneTimeTokenGenerationSuccessHandler : OneTimeTokenGenerationSucc
 ----
 ======
 
+[NOTE]
+====
+The URI passed to `generateTokenUrl` is matched literally.
+If you want it to live under your application servlet's base path, include that prefix explicitly — for example, `generateTokenUrl("/api/ott/generate")`.
+The same applies to `loginProcessingUrl` and `tokenGeneratingUrl` elsewhere on this page.
+====
+
 [[changing-submit-page-url]]
 == Changing the Default Submit Page URL
 

docs/modules/ROOT/pages/servlet/authentication/passwords/form.adoc

@@ -155,6 +155,15 @@ open fun filterChain(http: HttpSecurity): SecurityFilterChain {
 ----
 ======
 
+[NOTE]
+====
+The URI passed to `loginPage` (and to `loginProcessingUrl`, if set separately) is matched and redirected to literally.
+If your custom login page is served by an application servlet mapped under a base path, include that prefix in the URI you pass to the DSL.
+For example, if your dispatcher is at `/api/*`:
+
+include-code::./FormLoginServletPathConfiguration[tag=loginPage,indent=0]
+====
+
 [[servlet-authentication-form-custom-html]]
 When the login page is specified in the Spring Security configuration, you are responsible for rendering the page.
 // FIXME: default login page rendered by Spring Security

docs/modules/ROOT/pages/servlet/authorization/authorize-http-requests.adoc

@@ -642,6 +642,8 @@ This is because Spring Security requires all URIs to be absolute (minus the cont
 There are several other components that create request matchers for you like {spring-boot-api-url}org/springframework/boot/security/autoconfigure/web/servlet/PathRequest.html[`PathRequest#toStaticResources#atCommonLocations`]
 =====
 
+If most of your authorization rules sit under the same servlet path, you can xref:servlet/integrations/mvc.adoc#mvc-requestmatcher[publish a `PathPatternRequestMatcher.Builder` bean] with that base path; Spring Security then applies it to the string overloads of `authorizeHttpRequests((authorize) -> authorize.requestMatchers(...))`, `HttpSecurity#securityMatcher(...)` / `#securityMatchers(...)`, and `WebSecurityCustomizer#ignoring().requestMatchers(...)`.
+
 [[match-by-custom]]
 === Using a Custom Matcher