ReactiveCloudFoundryActuatorAutoConfiguration ignores firewall set on the WebFilterChainProxy when postprocessing it

[alfein]

Spring security fixed an issue in WebFilterChainProxy by allowing clients to override the default instance of the firewall field (ServerWebExchangeFirewall) with whatever client wants to or adjust the behavior of the default StrictServerWebExchangeFirewall instance:

spring-projects/spring-security#15974

However ReactiveCloudFoundryActuatorAutoConfiguration in the postProcess method overrides the default WebFilterChainProxy bean with new instance and ignoring any overrides of firewall the old bean had.

This causes apps that run on cloud foundry to not run the same way as they would outside of cloud foundry, and require my to disable cloud foundry management endpoints.

I think that's a bug

management:
  cloudfoundry:
    enabled: false

To test this behavior localy, set the VCAP_APPLICATION environment variable to something, json like.

[philwebb]

It looks like we might be quite limited in how we can fix this without some Spring Security updates. It doesn't look like we can get the existing value of the firewall field. The setFilterChainDecorator looks like it might be useful, but I don't think we can use it because it replaces the existing decorator.

@jzheaux Do you have any suggestions?

[alfein]

@philwebb , can you not do same as the security folks?

	@Bean(SPRING_SECURITY_WEBFILTERCHAINFILTER_BEAN_NAME)
	@Order(WEB_FILTER_CHAIN_FILTER_ORDER)
	WebFilterChainProxy springSecurityWebFilterChainFilter(ObjectProvider<ServerWebExchangeFirewall> firewall) {
		WebFilterChainProxy webFilterChainProxy = new WebFilterChainProxy(getSecurityWebFilterChains());
		firewall.ifUnique(webFilterChainProxy::setFirewall);
		return webFilterChainProxy;
	}

[philwebb]

That will work if the ServerWebExchangeFirewall is set from a bean, but if the user has called WebFilterChainProxy.setFirewall directly (or via a post processor), it won't work.

[alfein]

I think that's that was the way to override the firewall in spring security: spring-projects/spring-security@e48d6b0

[philwebb]

It's probably the most typical way, but I don't think it's the only way it could happen.