web.adoc 3.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147
  1. = Web Migrations
  2. == Favor Relative URIs
  3. When redirecting to a login endpoint, Spring Security has favored absolute URIs in the past.
  4. For example, if you set your login page like so:
  5. [tabs]
  6. ======
  7. Java::
  8. +
  9. [source,java,role="primary"]
  10. ----
  11. http
  12. // ...
  13. .formLogin((form) -> form.loginPage("/my-login"))
  14. // ...
  15. ----
  16. Kotlin::
  17. +
  18. [source,kotlin,role="secondary"]
  19. ----
  20. http {
  21. formLogin {
  22. loginPage = "/my-login"
  23. }
  24. }
  25. ----
  26. Xml::
  27. +
  28. [source,kotlin,role="secondary"]
  29. ----
  30. <http ...>
  31. <form-login login-page="/my-login"/>
  32. </http>
  33. ----
  34. ======
  35. then when redirecting to `/my-login` Spring Security would use a `Location:` like the following:
  36. [source]
  37. ----
  38. 302 Found
  39. // ...
  40. Location: https://myapp.example.org/my-login
  41. ----
  42. However, this is no longer necessary given that the RFC is was based on is now obsolete.
  43. In Spring Security 7, this is changed to use a relative URI like so:
  44. [source]
  45. ----
  46. 302 Found
  47. // ...
  48. Location: /my-login
  49. ----
  50. Most applications will not notice a difference.
  51. However, in the event that this change causes problems, you can switch back to the Spring Security 6 behavior by setting the `favorRelativeUrls` value:
  52. [tabs]
  53. ======
  54. Java::
  55. +
  56. [source,java,role="primary"]
  57. ----
  58. LoginUrlAuthenticationEntryPoint entryPoint = new LoginUrlAuthenticationEntryPoint("/my-login");
  59. entryPoint.setFavorRelativeUris(false);
  60. http
  61. // ...
  62. .exceptionHandling((exceptions) -> exceptions.authenticaitonEntryPoint(entryPoint))
  63. // ...
  64. ----
  65. Kotlin::
  66. +
  67. [source,kotlin,role="secondary"]
  68. ----
  69. LoginUrlAuthenticationEntryPoint entryPoint = LoginUrlAuthenticationEntryPoint("/my-login")
  70. entryPoint.setFavorRelativeUris(false)
  71. http {
  72. exceptionHandling {
  73. authenticationEntryPoint = entryPoint
  74. }
  75. }
  76. ----
  77. Xml::
  78. +
  79. [source,xml,role="secondary"]
  80. ----
  81. <http entry-point-ref="myEntryPoint">
  82. <!-- ... -->
  83. </http>
  84. <b:bean id="myEntryPoint" class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint">
  85. <b:property name="favorRelativeUris" value="true"/>
  86. </b:bean>
  87. ----
  88. ======
  89. == PortResolver
  90. Spring Security uses an API called `PortResolver` to provide a workaround for a bug in Internet Explorer.
  91. The workaround is no longer necessary and can cause users problems in some scenarios.
  92. For this reason, Spring Security 7 will remove the `PortResolver` interface.
  93. To prepare for this change, users should expose the `PortResolver.NO_OP` as a Bean named `portResolver`.
  94. This ensures that the `PortResolver` implementation that is used is a no-op (e.g. does nothing) which simulates the removal of `PortResolver`.
  95. An example configuration can be found below:
  96. [tabs]
  97. ======
  98. Java::
  99. +
  100. [source,java,role="primary"]
  101. ----
  102. @Bean
  103. PortResolver portResolver() {
  104. return PortResolver.NO_OP;
  105. }
  106. ----
  107. Kotlin::
  108. +
  109. [source,kotlin,role="secondary"]
  110. ----
  111. @Bean
  112. open fun portResolver(): PortResolver {
  113. return PortResolver.NO_OP
  114. }
  115. ----
  116. Xml::
  117. +
  118. [source,xml,role="secondary"]
  119. ----
  120. <util:constant id="portResolver"
  121. static-field="org.springframework.security.web.PortResolver.NO_OP">
  122. ----
  123. ======