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>