The spring.http.clients.cookie-handling property and
HttpClientSettings.cookieHandling() were honored by every imperative
ClientHttpRequestFactoryBuilder and by the Jetty, JDK and Reactor
ClientHttpConnectorBuilders, but HttpComponentsHttpAsyncClientBuilder
ignored the setting. As a result, a WebClient backed by Apache
HttpComponents kept storing cookies even when cookie handling was
disabled.
Map the setting to the default request config's cookie spec, as
HttpComponentsHttpClientBuilder already does, and document the property
alongside the other global HTTP client settings.
See gh-51724
Signed-off-by: Hyun Lee <dlwhdugs4147@gmail.com>
DevToolsPropertyDefaultsPostProcessor looked for
ConfigurableReactiveWebEnvironment
in org.springframework.boot.web.reactive.context by name, but the class
moved to org.springframework.boot.web.context.reactive in 4.0. As a
result, reactive web applications were never identified as web
applications and the hint about setting logging.level.web to DEBUG was
not logged for them.
ConfigurableReactiveWebEnvironment is part of spring-boot, so it is now
referenced directly rather than by name. The servlet environment check
is unchanged as spring-web is an optional dependency.
See gh-51708
Signed-off-by: ohchanKyu <okc0202@naver.com>
The default of @AutoConfigureTestDatabase's replace attribute changed
from ANY to NON_TEST in 3.4 but the manually declared metadata for
spring.test.database.replace still advertised "any" as the default.
See gh-51709
Signed-off-by: ohchanKyu <okc0202@naver.com>
Closes gh-51666
* gh-51666:
Polish "Use TLS port for Docker Compose RabbitMQ connection when SSL is configured"
Use TLS port for Docker Compose RabbitMQ connection when SSL is configured
When a rabbitmq Docker Compose service has SSL bundle labels,
RabbitDockerComposeConnectionDetailsFactory created an SslBundle but
still resolved the address from container port 5672, the plain AMQP
listener. As the connection factory enables SSL when an SslBundle is
present, the TLS handshake was attempted against the non-TLS listener
and the connection failed.
The address is now resolved from container port 5671 when an SslBundle
is present, matching RabbitStreamDockerComposeConnectionDetailsFactory
and the Testcontainers-based RabbitContainerConnectionDetailsFactory.
The SSL integration test now opens a connection using the resolved
address and SslBundle so that it fails without this fix.
Signed-off-by: ohchanKyu <okc0202@naver.com>
See gh-51666
The deprecation entry for
management.prometheus.metrics.export.pushgateway.base-url was declared
as "management.promethus", so the deprecation was never reported.
Signed-off-by: ohchanKyu <okc0202@naver.com>
See gh-51627
This commit improves TestImage so that an explicit image can trigger
the creation of the container, with optional additional setup. This
removes the need of creating additional container types for images that
have multiple flavors, and to please the static method that can only
create a container based on a single match.
Closes gh-51082
Prior to this commit, CloudFoundryReactiveActuatorAutoConfiguration
registered a BeanPostProcessor replaced the WebFilterChainProxy bean
with one that handled CF security and delegated to the existing
chain.
Constructing a new WebFilterChainProxy resulted in the loss of any
firewall customization on the existing chain as Spring Security does
not provide an API to retreive the firewall from the existing chain
and apply it to the new chain.
This commit changes the approach and aligns it with its Servlet
counterpart. Instead of post-processing the filter chain proxy, a new
SecurityWebFilterChain that handles cloudfoundryapplication/**
is defined. This chain becomes part of the existing
WebFilterChainProxy, preserving any firewall customization.
Signed-off-by: aashikantkumar <aashikantkumar2@gmail.com>
See gh-51549
Previously, the CloudFoundryAuthorizationExceptions thrown for a
missing application ID or cloud controller URL were not routed
through the error handling that turned them into a SecurityResponse
with a 503 status code. As a result, they were processed by the
general exception handling which resulted in a 500 response.
This commit updates the reactive SecurityInterceptor so that the
exceptions are processed through
SecurityInterceptor::getErrorResponse. This aligns the behavior of
the Cloud Foundry security intergration in a reactive application
more closely with that of a Servlet application.
Fixes gh-51613
Previously, the auto-configuration of reactive OAuth 2 resource
server based web security did not back off when a custom
SecurityWebFilterChain was defined. This did not match the
equivalent servlet-based auto-configuration which backs off when
a custom SecurityFilterChain is defined.
This commit updates the reactive auto-configuration to behave in
the same way as the servlet auto-configuration. A new annotation,
@ConditionalOnDefaultReactiveWebSecurity, is introduced. The
existing servlet-specific annotation,
@ConditionalOnDefaultWebSecurity is deprecated and a replacement
named @ConditionalOnDefaultServletWebSecurity is introduced.
Fixes gh-50778
Three Assert messages named a parameter that does not exist on the
method. In each case the correct name is already used by neighbouring
code in the same class.
Signed-off-by: kdomo <dongho5088@naver.com>
See gh-51568