Preserve firewall in reactive Cloud Foundry security auto-configuration - #51549
Open
aashikantkumar wants to merge 1 commit into
Open
Preserve firewall in reactive Cloud Foundry security auto-configuration#51549aashikantkumar wants to merge 1 commit into
aashikantkumar wants to merge 1 commit into
Conversation
Prior to this commit, `CloudFoundryReactiveActuatorAutoConfiguration` registered a `BeanPostProcessor` (`WebFilterChainPostProcessor`) that intercepted the primary `WebFilterChainProxy` bean and instantiated a second, new `WebFilterChainProxy` wrapping the original. Because constructing a new `WebFilterChainProxy` initializes its private `firewall` field with `new StrictServerWebExchangeFirewall()`, any custom `ServerWebExchangeFirewall` (configured either via a Spring `@Bean` or via `proxy.setFirewall(...)`) was lost. This commit aligns the reactive Cloud Foundry security configuration with its servlet counterpart (`IgnoredCloudFoundryPathsWebSecurityConfiguration` in `CloudFoundryActuatorAutoConfiguration`). The `BeanPostProcessor` is removed, and a dedicated `@Bean @order(-1) SecurityWebFilterChain` is registered for the path `/cloudfoundryapplication/**` with `permitAll()`, `csrf.disable()`, and CORS support. Spring Security's `ServerHttpSecurityConfiguration` collects this chain and places it with higher precedence inside the single, global `WebFilterChainProxy`. The existing proxy instance—including its custom firewall, decorators, and settings—remains untouched. Regression tests have been added to verify that: - A custom `ServerWebExchangeFirewall` bean is preserved on the proxy. - A firewall configured directly via a `BeanPostProcessor` calling `proxy.setFirewall(...)` is preserved. - The custom firewall is executed at runtime during request processing. - Application-defined `SecurityWebFilterChain` beans coexist with the Cloud Foundry chain under correct order. Closes spring-projectsgh-45377 Signed-off-by: aashikantkumar <aashikantkumar2@gmail.com>
spring-projects-issues
added
the
status: waiting-for-triage
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #45377
Hi team,
This PR addresses an issue where custom ServerWebExchangeFirewall configurations are lost when running reactive applications on Cloud Foundry.
What was happening?
When VCAP_APPLICATION is present, CloudFoundryReactiveActuatorAutoConfiguration used a BeanPostProcessor (WebFilterChainPostProcessor) to wrap WebFilterChainProxy.
The trouble with that approach is that instantiating a new WebFilterChainProxy creates a fresh instance with its private firewall field defaulting to new StrictServerWebExchangeFirewall(). As a result:
Any custom ServerWebExchangeFirewall bean declared by the user was discarded.
Direct customizations (e.g. calling setFirewall(...) on the proxy) were also lost.
Incoming requests were evaluated by the new proxy's strict firewall at the perimeter, rejecting valid requests that rely on customized firewall rules (like matrix parameters or specific URI encodings).
The Fix
Following @wilkinsona's suggestion in #45377, we aligned the reactive configuration with how the servlet side already handles this in IgnoredCloudFoundryPathsWebSecurityConfiguration:
Removed WebFilterChainPostProcessor.
Added a dedicated @order(-1) SecurityWebFilterChain bean matching /cloudfoundryapplication/** with permitAll(), csrf.disable(), and CORS configuration.
This allows Spring Security's native ServerHttpSecurityConfiguration to create and keep the single WebFilterChainProxy. Cloud Foundry routes are given higher precedence to bypass authentication, while the rest of the application's security configuration and the user's custom firewall remain completely untouched.
How this was verified
Added regression tests in CloudFoundryReactiveActuatorAutoConfigurationTests:
customFirewallBeanIsPreserved: Asserts that a custom ServerWebExchangeFirewall @bean stays on WebFilterChainProxy.
directlyConfiguredFirewallIsPreserved: Asserts that firewalls set directly via proxy.setFirewall(...) in a post-processor survive.
customFirewallIsInvokedOnRequests: Verifies runtime execution of firewall.getFirewalledExchange(...).
userSecurityWebFilterChainIsPreserved: Confirms that user-defined SecurityWebFilterChain beans coexist alongside the Cloud Foundry chain with correct ordering.
Ran:
bash
./gradlew :module:spring-boot-cloudfoundry:test
./gradlew :module:spring-boot-cloudfoundry:check
All reactive tests, servlet tests, checkstyle, and Spring JavaFormat checks pass cleanly.
Contributor Checklist
Signed-off-by trailer included in commit for DCO
Code formatted with Spring JavaFormat
Checkstyle checks pass
@author tag added
Unit/slice regression tests added