x-forwarded-proto broken in Spring Boot 2.1.1

[CalamarBicefalo]

For the following test:

@Test
fun `GET links uses proto headers`() {
     mvc.perform(get("/v1/").header("x-forwarded-proto", "https"))
              .andExpect(status().isOk)
              .andExpect(jsonPath("$._links.activate.href", startsWith("https")))
}

And the following implementation:

private fun buildLinkForUser(currentUser: User) =  
entityLinks.linkToCollectionResource(UserResource::class.java).withRel("activate")

Or alternatively with controller links, e.g.:

fun buildLinkForUser(): Link = linkTo(methodOn(UserController::class.java).activate())
                .withRel("activate")

I get the test passing in Spring Boot 2.0.7 and failing in Spring Boot 2.1.1 - because the link gets http instead of https.

I checked Spring Hateoas in both boot releases and it remains 0.25.0. Obviously, this makes me think this issue doesn't belong here. However, I was hoping you could help me reassign it where it belongs?

[wilkinsona]

Thanks for the report, unfortunately, there isn't enough information here to diagnose where the problem might have been introduced. Can you please provide a minimal sample (something that we can unzip or git clone and run) that reproduces the behaviour you have described?

[gregturn]

Spring Framework 5.1 (from Boot 2.1) alters forwarded header handling and we haven’t merge our patch to compensate for this.

See #713.

[CalamarBicefalo]

Do you then need this zip @gregturn ? Or do you have enough context?

[CalamarBicefalo]

Either way, here it is @gregturn, @wilkinsona, just upgrade boot and you'll see that one test failing.
user-service.zip

[gregturn]

#758 has been merged to master and backported so you can find it in Spring HATEOAS 1.0.0.BUILD-SNAPSHOT (and soon 0.25.1.RELEASE).

If you test your app against this most recent change (and also configure Forwarded headers properly with Spring MVC), your issue should clear up.

If not, please provide more details.

[ilya40umov]

I have the same problem while trying to migrate to 2.1.1.
https://github.com/ilya40umov/KotLink/blob/master/src/test/kotlin/org/kotlink/KotLinkSecurityAndSslTest.kt
Which works perfectly fine on 2.0.x, starts failing on 2.1.1 with
Caused by: java.lang.AssertionError: Response header 'Location' expected:<[https://localhost/]> but was:<[http://localhost:37359/]>
I'm not using hateoas, so my question is if I should fine another bug against Spring MVC?

P.S. Forwarding headers are configured here:
https://github.com/ilya40umov/KotLink/blob/master/src/main/resources/application-local.yaml
P.S.S. If anybody will want to run the test, you can find more instructions on setting-up the environment here:
https://github.com/ilya40umov/KotLink/blob/master/docs/engineering-guide.md

Edit: I have moved to a new desktop and for whatever reason I can't reproduce the issue anymore.

[gregturn]

If this is purely Spring Boot and not Spring HATEOAS then you need to open a ticket with Spring Boot.

[Bert-R]

@gregturn You said

(and soon 0.25.1.RELEASE)

Is this still coming? It would be tremendously helpful for us if a fix could be released soon.

[gregturn]

Test it out against 0.25.1.BUILD-SNAPSHOT and tell me if it works.

[jenny1976]

we currently use this SNAPSHOT and it works.

[Bert-R]

It unfortunately does not work for us. With Spring Boot 2.0, the protocol worked, based on the X-Forwarded-Proto header, but now it doesn't work anymore.

[gregturn]

Have you created the right filter? If you check this ticket there’s a link about how to properly activate forwarded headers.

[Bert-R]

After adding server.use-forward-headers=true, it works. Since when is this setting necessary? We never used it and it always worked.

With my confirmation (and also from @jenny1976), would you be willing and able to release 0.25.1?

[jenny1976]

@gregturn
We would also appreciate a 0.25.1 Release because using a SNAPSHOT in production of course is not a Problem here but nevertheless makes us developers feel a bit nervous :)

[gregturn]

Spring Framework now defaults with Forwarded header support disabled. So you have to use that setting for any apps you need from here on.

I’ll consult with @odrotbohm about seeing if we can get a patch release out the door.

[Bert-R]

@gregturn Any news on this?

[odrotbohm]

We can ship an 0.25.1 next week for inclusion in Spring Boot 2.1.3.

[Bert-R]

That would be great. Thanks in advance!

[vjnaidu]

Once the patch is release would the "spring-boot-starter-hateoas" automatically pull the new patch 0.25.1.RELEASE as its dependency?

[gregturn]

That will require a separate patch.

However, at any point, you can put this into your build file:

<spring-hateoas.version>0.25.1.BUILD-SNAPSHOT</spring-hateoas.version>

...and adjust it based on the release. (Comparable mod available if you are using Gradle).

[dinkarchaturvedi]

Saw a comment from @Bert-R mentioning that server.use-forward-headers=true works to bypass this issue in case of Spring Boot. Is there any Spring 5 XML equivalent for this?
We recently upgraded to Spring 5.1.3 and Hateoas to 0.25.0.RELEASE and started facing this issue where in case of a request coming from within the system (as opposed to from the client via the LB), the X-Forwarded-Host is not used while generating the links.
Also, when is 0.25.1 expected to be release independently?

[agebhar1]

If anybody struggles with this issue there is a fine workaround (?):

@Bean                                                                                                                                                                                                                                                                                                                                                                                 
public FilterRegistrationBean<ForwardedHeaderFilter> forwardedHeaderFilter() {                                                                                                                                                                                                                                                                                                        
    final FilterRegistrationBean<ForwardedHeaderFilter> filter = new FilterRegistrationBean<>();                                                                                                                                                                                                                                                                                  
    filter.setFilter(new ForwardedHeaderFilter());                                                                                                                                                                                                                                                                                                                                
    return filter;                                                                                                                                                                                                                                                                                                                                                                
} 

taken from https://stackoverflow.com/a/53269319

[odrotbohm]

Spring HATEOAS 0.25.1 was just released and is ready for pickup in Spring Data Lovelace SR coming tomorrow and Spring Boot 2.1 maintenance release.

[Bert-R]

@dinkarchaturvedi Besides setting server.use-forward-headers=true, you also need to use release 0.25.1.

[dinkarchaturvedi]

Thanks @Bert-R . The Spring setting server.use-forward-headers appears to be specific to Spring Boot (I could be wrong) and meant to be used within application.properties file.
However, since we are using Spring 5.1, configured using XML, within a conventional web application running a standalone tomcat, I couldn't find an equivalent of this setting that can be used within XML. Could you share some documentation or links where I can find XML equivalent of server.use-forward-headers setting?

[gregturn]

There is a bean definition listed above with a link to SO showing how to define the necessary bean.

[dinkarchaturvedi]

Thanks @gregturn . Apologies for posting on a closed issue but none of the solutions mentioned in this thread have helped my case. The SO link suggests to use FilterRegistrationBean which is available in SpringBoot but not as part of Spring Core 5.1 so I can't use that.
Also, I couldn't find XML equivalent for server.use-forward-headers setting that is used in application.properties in SpringBoot but our Spring configuration comes from XML.
I have upgraded the Hateoas to 0.25.1.Release version and hoping to find a way to fix the problem.

[raphaelLacerda]

i´ve recently upgraded from 1.5.4 to 2.1.4 and i´ve had the same issue.

With server.use-forward-headers=true on application.properties it´s fixed

[taleodor]

Thank you very much @raphaelLacerda - adding server.use-forward-headers=true fixed it for me as well.

[redent]

For future readers, use-forward-headers has been deprecated in favour of forward-headers-strategy:

server.forward-headers-strategy=native

forward-headers-strategy defaults to none.

[arung0wda]

For future readers, use-forward-headers has been deprecated in favour of forward-headers-strategy:

server.forward-headers-strategy=native

forward-headers-strategy defaults to none.

Can somebody explain how NATIVE and FRAMEWORK are different for this property? When should I use one over the other?

[odrotbohm]

See the Javadoc on the corresponding enum.

[arung0wda]

See the Javadoc on the corresponding enum.

I did. But it doesn't give enough information for me to choose between Native/Framework. All it says is who handles forwarded headers for corresponding values. servlet container? or spring framework? but it brings back to square 1. Should I let container handle it? or the framework? when Should I prefer one over the other?

I've posted a question on stackoverflow regarding the same
https://stackoverflow.com/questions/68318269/

[odrotbohm]

There already is an answer and discussion on the Stack overflow post. This ticket is the least appropriate place to discuss this.