Setting spring.ldap.embedded.ssl.enabled without an SSL bundle started a
plain LDAP listener silently. It now fails at startup as a bundle is
required to provide the server's certificate and private key.
Closes gh-51471
Configure the SSL bundle through the context source's base environment
rather than a DirContextAuthenticationStrategy. The strategy is not
consulted when read-only operations use an anonymous environment,
which is the default when no username is set, so LDAPS connections
silently used the JVM's default trust material. It was also bypassed
entirely when a custom strategy bean was defined.
Register an SSL bundle update handler so that reloaded key and trust
material is used by subsequent connections.
Target LDAPS rather than StartTLS by setting the JNDI
java.naming.ldap.factory.socket property, and fail at startup if a
bundle is combined with a non-ldaps URL or with a socket factory that
has also been set through spring.ldap.base-environment. Delegate all
socket factory methods so that a configured connect timeout is
applied.
Add spring.ldap.ssl.enabled to use the platform's default trust and
key material without a bundle, default the URL to
ldaps://localhost:636 when SSL is enabled, and register the reflection
hint that JNDI needs to load the socket factory by name in a native
image. Cover the result with integration tests that search over LDAPS
against OpenLDAP and LLDAP containers, including certificates that are
untrusted or issued to a different host.
See gh-51382
Derive logging.pattern.correlation from the configured MDC keys so that
log correlation keeps working when the keys are customized, instead of
silently rendering a blank correlation field.
Reject empty MDC keys and only clear Brave's default correlation fields
when the keys have been customized, so that applications using the
defaults are unaffected if Brave adds a default field.
Replace the tests that asserted on bean wiring with integration tests
covering the MDC contents, plus a smoke test for the log output.
See gh-50595
Servlet web security moved to ServletWebSecurityAutoConfiguration, but
the MVC Security section still describes SecurityAutoConfiguration
importing SpringBootWebSecurityConfiguration, which no longer exists.
See gh-51411
Signed-off-by: Alexander Makarov <alexander.makarov@nightsong.li>
The auto-configuration for the InfluxDB client was removed in 3.4.0, but
the NoSQL section of the reference documentation still described it.
See gh-51172
Signed-off-by: Alexander Makarov <alexander.makarov@nightsong.li>
This commit introduces new properties for configuring the HTTP headers
that should be used for forward support.
The new `server.netty.forwarded-headers.header-format` property allows
"standard" or "x_forwarded" to select "Forwarded" or "X-Forwarded-*"
headers.
This aligns the behavior of Netty server with the "FRAMEWORK" strategy.
Closes gh-51031
This commit introduces new properties for configuring the HTTP headers
that should be used for forward support.
The new `server.jetty.forwarded-headers.header-format` property allows
"standard" or "x_forwarded" to select "Forwarded" or "X-Forwarded-*"
headers.
This aligns the behavior of Jetty server with the "FRAMEWORK" strategy.
Closes gh-51148
Prior to this commit, Spring Boot would auto-configure the
`ForwardedHeaderFilter`/`ForwardedHeaderTransformer` when the "NATIVE"
strategy is chosen.
Spring Framework now requires an explicit choice between the supported
HTTP header variants as of spring-projects/spring-framework#37072.
This commit adapts to this new behavior with the following:
* the "FRAMEWORK" strategy now only applies to Spring MVC and Spring
WebFlux applications, since "NATIVE" strategies are now a good choice
for most deployments.
* the format of HTTP headers is now configured with
`spring.mvc.forwarded-headers.header-format` and
`spring.webflux.forwarded-headers.header-format`, with additional
options.
The default header format is now "X-Forwarded-*" for both NATIVE and
FRAMEWORK strategies. The reference documentation also reflects those
changes.
Closes gh-51030
With Spring Framework 7.1 deprecating RestTemplate for removal, this
commit deprecates our supporting infrastructure as well, and steers
users towards RestClient instead:
* RestTemplateAutoConfiguration and
RestTemplateObservationAutoConfiguration
* RestTemplateBuilder, RestTemplateBuilderConfigurer, and
RestTemplateBuilderClientHttpRequestInitializer
* RestTemplateCustomizer, RestTemplateRequestCustomizer, and
ObservationRestTemplateCustomizer
* MockRestServiceServerAutoConfiguration,
MockServerRestTemplateCustomizer, and RootUriRequestExpectationManager
in the test support module
The reference documentation no longer covers RestTemplate and now
solely documents RestClient and WebClient. Code snippets and sample
tests that only existed to illustrate RestTemplate usage have been
removed accordingly.
Closes gh-51118
Moritz Halbritter
Phillip Webb
chisanw
Alexander Makarov
Stéphane Nicoll
Brian Clozel
wantaek
Stefano Cordio