Using spring-hateoas behind a HTTPS proxy

[lorethan]

Hi.

I am using the ControllerLinkBuilder to generate links for my responses, but I am not able to override the protocol in any way. The proxy (Hiawatha) uses https, but forwards to my tomcat server with http.

Is there anything I have missed that should make this possible, or is the some hook that could make this possible in any way?

[Laures]

your proxy should set specific headers that contain the original uri (which includes https) like x-forwarded-proto.
your servlet container then should adhere to these headers so the current request used by spring contains https://wherever/your/service/is

[odrotbohm]

@lorethan - Any further feedback to what @Laures wrote?

[lorethan]

I solved my problem by adding a HttpServletRequestWrapper in a servlet filter when x-forwarded-* headers are present, and that solved my problem. But it could be more elegant and require less code if the ControllerLinkBuilder class could respect these headers if such a feature were enabled.

[odrotbohm]

The ControllerLinkBuilder already considers X-Forwarded-* headers if they're set appropriately by the infrastructure. So I'd argue it's a matter of configuring the proxy correctly.

[lorethan]

I can see now that support is there (X-Forwarded-Ssl). Not sure if it was there when I added this issue (pretty sure is was not).

Anyways, I will gladly close this issue now :)

[odrotbohm]

You're right, @lorethan. The fix was introduced with the fix for #112. I guess we prefered that because of the attached pull request. Anyway, glad it works for you now! :)

[ulsa]

The code for ControllerLinkBuilder suggests that only X-Forwarded-Ssl is used to determine the scheme. However, Amazon's load balancer sets X-Forwarded-Proto and X-Forwarded-Port. Does anyone know how this will play out?

[dominicfarr]

X-Forwarded-Ssl is non-standard as far as I can tell.

X-Forwarded-Proto is a defactor standard according to Wikipedia: List_of_HTTP_header_fields

For those of us that are using Amazon AWS, and off-loading SSL at the AWS Load Balancer, we are limited to X-Forwarded-Proto, as these machines are not configurable by users.

ControllerLinkBuilder isn't extendable, as it is package protected. Furthermore, ControllerLinkBuilder.getBuilder() is static, so cannot be overridden. Therefore, I've created a fork and added X-Forwarded-Proto to the builder. See fork #257

Without this I cannot run any spring-haeoas in production.

[andreasevers]

I'm wondering how you would forward a prefix of the URI.

Considering @Laures mentioning "https://wherever/your/service/is", would it be possible to get the following scenario to work:

The gateway is located on:
https://www.test.com/TESTPREFIX/customer/123
While the actual endpoint is located on:
http://blabla.internal/customer/123

The actual endpoint has a link to:
http://blabla.internal/customer/123/products

And that link should be returned to the gateway as:
https://www.test.com/TESTPREFIX/customer/123/products

In this scenario I can use "X-Forwarded-Proto" and "X-Forwarded-Host" (or its Forwarded equivalents), but how would I forward the prefix?

[andreasevers]

Seems like "X-Forwarded-Prefix" did the trick for me, but I don't understand completely why.

[dominicfarr]

@lorethan See, https://jira.spring.io/browse/SPR-12500 why this works.

[jhusson]

With Apache in front of tomcat, you can resolve the problem by specifing the header _X-Forwarded-Proto_ as part of your virtual host configuration

<VirtualHost *:443>
RequestHeader set X-Forwarded-Proto "https"
ProxyPreserveHost On
ServerName www.example.com

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

<Location/>
    SSLRequireSSL
</Location>

ProxyPass / http://127.0.0.1:9000/
ProxyPassReverse / http://127.0.0.1:9000/
</VirtualHost>

[seansms]

I don't have control over the header. Our networking team has chosen a proprietary header because the "standard" header has unpredictable results. It would be useful if we could specify our own header.

[seansms]

I just wrote a shim to transform the link based on the request header to resolve it for now.

[rbuer]

For those having this issue with Spring > 5.1: It handles the forward-headers properly, but you have to enable it by setting the property server.use-forward-headers=true

[gregturn]

You can read it in detail => https://docs.spring.io/spring-hateoas/docs/1.0.0.RC2/reference/html/#server.link-builder.forwarded-headers

[pcornelissen]

Requiring my clients to provide the header is bad and error prone. To have to fake the forwarded header doesn't seem a too good idea either (obfuscates the fact that you just want to set the hostname for generated links and may have side effects that are non obvious)

Why not provide a property or a way to set the hostname programmatically for the HATEOAS link-generation?
The spring way would be to have some kind of hostname provider bean that you override if you need special handling. That feels much more "spring-ish" to me.

[gregturn]

What is the configuration of yours servers? Because this is textbook cloud configuration. Having an app behind a load balancer KNOW what the load balancer knows sort of de-inverts things.

[pcornelissen]

It's not a real loadbalancer, when you use Eureka or consul to make client side loadbalancing using service-IDs, then you don't have forwarded headers.

[gregturn]

Since we aren’t talking about an HTTP proxy, would you be willing to open a new ticket?