Allow url to be specified when working with @AutoConfigureWebMvc configured HtmlUnit beans

[rwinch]

Please update the autowired UriBuilderFactoryWebClient to support configuring the port of the base URL as was allowed with LocalHostWebClient.

Configuring the port is important for Spring Security applications because many tests will involve multiple servers with different ports being an important part of the assertions. For example, when using an Authorization Server the URLs that are redirected to will need to be the same as the Authorization Server's ports but must be different from the port of the OAuth Client.

Related spring-projects/spring-framework#35709

[philwebb]

The old code was a little unusual because it was setting up the mock so there was no real server port to obtain. I'm guess the issue is probably because the old code ended up defaulting to 8080 for the port whilst the new code just leaves it off. I suspect the fact that we no longer have any port is triggering spring-projects/spring-framework#35709.

I think if we change our default URL to http://localhost:8080 rather than http://localhost the framework bug would not happen (but I'd rather the framework bug was fixed).

@rwinch How were you configuring the port for the old version? Did you set local.server.port manually? Or would hardcoding 8080 fix things for you? Have you got a sample or test we can look at?

[rwinch]

Thanks @philwebb

The old code was a little unusual because it was setting up the mock so there was no real server port to obtain.

I think that it makes sense for the mock to use the same URL as the server. Using the same port makes the mock behave as similar to integration tests as possible. Aligning the mock with the configured server port helps because any testing/validation with the application is aligned with the configuration vs having to produce a new test configuration (although test configurations are still permissible for testing other conditions).

For example, a typical Spring Security application configures various URLs that ensure that the port must be aligned. An example is the OAuth Issuer. Spring Security will ensure that the requested URL is aligned with what is configured in the application. By defaulting the port to the configured port, the user is able to use the production (or development) configuration in their tests.

I think if we change our default URL to http://localhost:8080 rather than http://localhost the framework bug would not happen (but I'd rather the framework bug was fixed).

To be clear, I do think that Framework should fix the bug and I do not view this as a workaround for the Framework bug.

I think that this provides value in itself because it makes it easier for users to use existing Spring Security configuration (which includes ports that will be validated based on what is used in development/production) and the autowired WebClient.

How were you configuring the port for the old version? Did you set local.server.port manually?

Specifying the local.server.port using @TestPropertySource is something that worked well previously. Currently, the workaround (that I'm aware of) is users can publish their own MockMvcWebClientBuilder Bean in their tests:

@Bean
static MockMvcWebClientBuilder webClientBuilder(MockMvc mockMvc, Environment env) {
	String serverPort = env.getProperty("server.port", "8080");
	String baseUriPort = env.getProperty("local.server.port", serverPort);
	UriComponentsBuilder baseUri = UriComponentsBuilder.fromUriString("http://localhost")
		.port(baseUriPort);
	DefaultUriBuilderFactory factory = new DefaultUriBuilderFactory(baseUri);
	UriBuilderFactoryWebClient delegate = new UriBuilderFactoryWebClient(factory);
	return MockMvcWebClientBuilder.mockMvcSetup(mockMvc).withDelegate(delegate);
}

[philwebb]

I think that it makes sense for the mock to use the same URL as the server. Using the same port makes the mock behave as similar to integration tests as possible

There's usually not an actual server running when using Mock MVC so nothing is actually setting local.server.port. Do you have a test we can debug that works in 3.5 but fails with 4.0? That would help us understand why 3.5 works and 4.0 does not. I'm not keen to simply copy the server.port property because the that might configuring an ephemeral port.

[rwinch]

Sorry that I wasn't clear. I'm not too worried about how the port is set, but what is valuable is allowing the port to be configured (to match other configurations) without needing to define MockMvcWebClientBuilder.

A real test is demoed in the referenced commit. However, it is a bit complex.

This issue comes up when a user needs to create a URL from the exiting HttpServletRequest and ensure that the port is reflected in that URL. This might be an explicit validation by the user or more likely an implicit validation (performed by a protocol like OAuth based upon configuration of OAuth Issuer). This implicit validation is very common in Single Sign On protocols to ensure that an open redirect vulnerability is not present.

I've put together a minimal example that demonstrates this:

• Easily able to configure the port that is used in Boot 6 https://github.com/rwinch/spring-sample/tree/boot6-gh-47857
• Cannot easily configure the port that is used in Boot 7 https://github.com/rwinch/spring-sample/tree/boot7-gh-47857

[philwebb]

Ahh OK, thanks for the sample. I see @TestPropertySource(properties = "local.server.port=9090") so that explains what I was missing.