spring-cloud
View logs if spring-cloud-data-flow-server is running behind a reverse proxy is not possible
Description: If you use spring-cloud-data-flow-server behind a reverse proxy it is not possible to view the logs within the ui as the "_links" are calculated from the backend with its own domain name.
Release versions: 2.11.2
Custom apps: N/A
Steps to reproduce: Use spring-cloud-data-flow-server behind a reverse proxy.
Screenshots: N/A
Additional context: PR in SCDF UI will be provided to fix this issue
@klopfdreh Is your reverse proxy configured to add headers: X-Forwarded-Proto, X-Forwarded-Port
@klopfdreh Is your reverse proxy configured to add headers:
X-Forwarded-Proto,X-Forwarded-Port
Yes, but the way the API is implemented the request does not respect any headers but uses only the domain of the backend. See the PR for more details.
@klopfdreh Is your reverse proxy configured to add headers:
X-Forwarded-Proto,X-Forwarded-PortYes, but the way the API is implemented the request does not respect any headers but uses only the domain of the backend. See the PR for more details.
Have you tried server.forward-headers-strategy=NATIVE and server.forward-headers-strategy=FRAMEWORK?
@klopfdreh Is your reverse proxy configured to add headers:
X-Forwarded-Proto,X-Forwarded-PortYes, but the way the API is implemented the request does not respect any headers but uses only the domain of the backend. See the PR for more details.
If you have multiple load-balancers en-route the addition of x-forwarded headers should be disabled on the intermediate LBs/ingress servers.
Hey @corneil,
I checked both server settings, now. With server.forward-headers-strategy=NATIVE and with server.forward-headers-strategy=FRAMEWORK the URLs are still shipped with the domain of the backend but not with the reverse proxy if you access the endpoint through the reverse proxy.
Can the ingress on k8s be configured to leave the x-forwarded headers in place instead of replacing with the cluuster dns?
The issue here is that the Angular frontend does not send the header to tell the backend to use the scheme / domain / port from the reverse proxy. (No x-forwarded-for)
List of all request headers:
To my understanding the headers must be added, or we can use my code to adjust the url to fit the one of the frontend without any infrastructure changes.
@klopfdreh The reverse proxy has to be configured to add the x-forwarded-* headers and the loadbalancer/ingress has to be configured to not override the x-forwarded-* headers
@klopfdreh This may apply https://github.com/kubernetes/ingress-nginx/issues/5701#issuecomment-643024643
I am going to ask if we can apply those changes and report back. 👍 But maybe it would be nice to have this option as well - in this case (with my changes) no reverse proxy changes are required.
@klopfdreh we are going to push this to the next release as we are still not sure which direction we want to go and we are starting the release process in the next 1-2 days. Let's see how things are once the changes are applied (if that is possible). Thank you for your patience.
Hey @onobc - no problem - we are also having a look at this issue and try to adjust some things in our infra. 👍
Hey @onobc / @corneil
I know that in normal cases if you configure the backend correctly (tomcat) and apply the header in the reverse proxy, the client should translate the response _links to the reverse-proxy domain
However, I asked our infra team and it seems that they can set the header but be able not fill them. So I kindly ask if there is a way to implement this feature as sort of compatiblitiy mode for reverse proxies which are not able to set those headers? So in the settings a toggle and if you activate it the header all of the _link urls is translated the way I implemented it.
That would be awesome.
Hi @klopfdreh , I would not be opposed to adding the feature in an opt-in fashion. I am not sure when we will be able to get to it. If you could adjust the code proposal to include this, that would help w/ timeline.
Thanks, Chris
Wow @klopfdreh - that was fast. I hope that I did not mislead you but we are currently in the process of releasing 2.11.3 (UI 3.4.3) and will look at this once the release is complete.
Hey @onobc - no problem - I am just so glad that this feature is accepted. 👍
@onobc - as the PR was reviewed by @oodamien and the 2.11.4 release is out - I think we can merge it to be in 2.11.5 and close the issue.