ReactorServerHttpRequest.getUri() does not include scheme [SPR-15931]

[spring-projects-issues]

Abhijit Sarkar opened SPR-15931 and commented

ServerRequest.uri() returns a relative URI that starts with //, thus making it impossible to extract the scheme. The scheme is required when working with OAuth that requires a redirect URL to be sent with the initial request.

Here's a sample OAuth call for Pinterest:

fun redirect(request: ServerRequest): Mono<ServerResponse> =
    UriComponentsBuilder.fromUriString("https://api.pinterest.com/oauth/")
            .queryParam("response_type", "code")
            .queryParam("scope", "read_public,write_public")
            .queryParam("state", state)
            .queryParam("client_id", clientId)
            .queryParam("redirect_uri", request.uri().resolve(URI.create("oauth/token"))
                    .let { uri -> (uri.scheme ?: "https").let { "$it:$uri" } })
            .build()
            .toUri()
            .also { logger.debug("Making request to: $it.") }
            .let { ServerResponse.permanentRedirect(it).build() }

fun accessToken(request: ServerRequest): Mono<ServerResponse> =
    request
            .also {
                logger.debug("Received access token: $it.")
                it.queryParam("state")
                        .filter { it == state }
                        .flatMap { request.queryParam("code") }
                        .ifPresent { cache.put("accessToken", it) }
            }
            .let { ServerResponse.noContent().build() }

---

Affects: 5.0 RC3

Issue Links:

• WebFlux equivalent of MvcUriComponentsBuilder [SPR-15953] #20505 Introduce WebFluxUriComponentsBuilder
• Introduce ForwardedHeaderFilter for WebFlux [SPR-15954] #20506 Introduce ForwardedHeaderFilter for WebFlux

Referenced from: commits 4a0784b, ec6475a

[spring-projects-issues]

Arjen Poutsma commented

Fixed in ec6475a

[spring-projects-issues]

Abhijit Sarkar commented

@arjen.poutsma, thanks for the quick turnaround. I looked at the commit and looks like the unit test verifies only http scheme. Shouldn't it do more?

[spring-projects-issues]

Arjen Poutsma commented

Currently, we don't have any SSL integration tests set up. If time permits, I see if I can add some.

[spring-projects-issues]

Abhijit Sarkar commented

Sorry to reopen this, but it doesn't resolve the scheme correctly, always falling back to http. Made request to "https://pinterest-client.herokuapp.com/oauth", in the code request.uri().resolve("/oauth/token") returns "http://pinterest-client.herokuapp.com/oauth/token", causing OAuth to fail.

[spring-projects-issues]

Steve Storey commented

I think the code also needs to be looking to see if there was an "X-Forwarded-Proto" header rather than just seeing if this connection involved an SSL handler so that requests being SSL terminated by a proxy (e.g. nginx) and forwarded onto the Java (over plain HTTP) still get the correct scheme detected.

[spring-projects-issues]

Arjen Poutsma commented

When used in a forwarding setup, X-Forwarded-Proto definitely contains the scheme information of the client-originated request. However, ServerRequest.getUri()) is meant to return the URI of that particular request; not that of the originating request. As such, the header cannot be used to determine the scheme that is returned from getUri(). We do have various components available that aid with X-Forwarded Headers though, see the UriComponentsBuilder#fromHttpRequest, for instance.

I've added an additional integration test here, which sets up a Reactor HTTPS server using a self-signed certificate, and tests whether the scheme is detected as HTTPS. It seems to work fine.

My guess is that Abhijit Sarkar's app is deployed in such a forwarding setup, where Reactor is not the one dealing with SSL, but rather some other forwarding HTTP server is. As such, the scheme of the Reactor request is correctly identified as http.

[spring-projects-issues]

Arjen Poutsma commented

Some follow-up: I have created two separate issues which, once implemented, should make it easier to deal with X-Forwarded headers. See #20505 and #20506.