148 lines
3.0 KiB
Plaintext
148 lines
3.0 KiB
Plaintext
= Web Migrations
|
|
|
|
== Favor Relative URIs
|
|
|
|
When redirecting to a login endpoint, Spring Security has favored absolute URIs in the past.
|
|
For example, if you set your login page like so:
|
|
|
|
[tabs]
|
|
======
|
|
Java::
|
|
+
|
|
[source,java,role="primary"]
|
|
----
|
|
http
|
|
// ...
|
|
.formLogin((form) -> form.loginPage("/my-login"))
|
|
// ...
|
|
----
|
|
|
|
Kotlin::
|
|
+
|
|
[source,kotlin,role="secondary"]
|
|
----
|
|
http {
|
|
formLogin {
|
|
loginPage = "/my-login"
|
|
}
|
|
}
|
|
----
|
|
|
|
Xml::
|
|
+
|
|
[source,kotlin,role="secondary"]
|
|
----
|
|
<http ...>
|
|
<form-login login-page="/my-login"/>
|
|
</http>
|
|
----
|
|
======
|
|
|
|
then when redirecting to `/my-login` Spring Security would use a `Location:` like the following:
|
|
|
|
[source]
|
|
----
|
|
302 Found
|
|
// ...
|
|
Location: https://myapp.example.org/my-login
|
|
----
|
|
|
|
However, this is no longer necessary given that the RFC is was based on is now obsolete.
|
|
|
|
In Spring Security 7, this is changed to use a relative URI like so:
|
|
|
|
[source]
|
|
----
|
|
302 Found
|
|
// ...
|
|
Location: /my-login
|
|
----
|
|
|
|
Most applications will not notice a difference.
|
|
However, in the event that this change causes problems, you can switch back to the Spring Security 6 behavior by setting the `favorRelativeUrls` value:
|
|
|
|
[tabs]
|
|
======
|
|
Java::
|
|
+
|
|
[source,java,role="primary"]
|
|
----
|
|
LoginUrlAuthenticationEntryPoint entryPoint = new LoginUrlAuthenticationEntryPoint("/my-login");
|
|
entryPoint.setFavorRelativeUris(false);
|
|
http
|
|
// ...
|
|
.exceptionHandling((exceptions) -> exceptions.authenticaitonEntryPoint(entryPoint))
|
|
// ...
|
|
----
|
|
|
|
Kotlin::
|
|
+
|
|
[source,kotlin,role="secondary"]
|
|
----
|
|
LoginUrlAuthenticationEntryPoint entryPoint = LoginUrlAuthenticationEntryPoint("/my-login")
|
|
entryPoint.setFavorRelativeUris(false)
|
|
|
|
http {
|
|
exceptionHandling {
|
|
authenticationEntryPoint = entryPoint
|
|
}
|
|
}
|
|
----
|
|
|
|
Xml::
|
|
+
|
|
[source,xml,role="secondary"]
|
|
----
|
|
<http entry-point-ref="myEntryPoint">
|
|
<!-- ... -->
|
|
</http>
|
|
|
|
<b:bean id="myEntryPoint" class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint">
|
|
<b:property name="favorRelativeUris" value="true"/>
|
|
</b:bean>
|
|
----
|
|
======
|
|
|
|
== PortResolver
|
|
|
|
Spring Security uses an API called `PortResolver` to provide a workaround for a bug in Internet Explorer.
|
|
The workaround is no longer necessary and can cause users problems in some scenarios.
|
|
For this reason, Spring Security 7 will remove the `PortResolver` interface.
|
|
|
|
To prepare for this change, users should expose the `PortResolver.NO_OP` as a Bean named `portResolver`.
|
|
This ensures that the `PortResolver` implementation that is used is a no-op (e.g. does nothing) which simulates the removal of `PortResolver`.
|
|
An example configuration can be found below:
|
|
|
|
[tabs]
|
|
======
|
|
Java::
|
|
+
|
|
[source,java,role="primary"]
|
|
----
|
|
@Bean
|
|
PortResolver portResolver() {
|
|
return PortResolver.NO_OP;
|
|
}
|
|
----
|
|
|
|
Kotlin::
|
|
+
|
|
[source,kotlin,role="secondary"]
|
|
----
|
|
@Bean
|
|
open fun portResolver(): PortResolver {
|
|
return PortResolver.NO_OP
|
|
}
|
|
----
|
|
|
|
Xml::
|
|
+
|
|
[source,xml,role="secondary"]
|
|
----
|
|
|
|
<util:constant id="portResolver"
|
|
static-field="org.springframework.security.web.PortResolver.NO_OP">
|
|
----
|
|
======
|
|
|