Thredds do not behave well behind Nginx proxy serving as SSL termination #1310
Comments
|
Thank you for passing along your nginx config - I think we're getting close to being able to document this setup, but not quite yet. Here is my understanding of the overall situation: When obtaining information about incoming requests (ip addresses, for example), the TDS uses the Java Servlet API, so it only "sees" what the servlet container passes it. This gives server administrators the ability to choose a servlet container of their choice (e.g. Jetty, GlassFish, WebSphere, JBoss, etc.), as long as it supports the proper version of the servlet specification (3.0 in the case of the TDS). The TDS Docker image uses Tomcat as the servlet container. When you add a proxy, you have to make sure that the proxy server and the servlet container are configured properly so that the correct information makes it from the proxy through the servlet container to the application (i.e. the TDS), and that they servlet container can get the response information from the application back to the proxy. Because there are a number of combinations of proxy server / servlet container combinations, there isn't one single configuration that can be used. We've documented the one we know and use. The solution you found for getting https to work adds a Connector to Tomcat to properly interface with nginx to make sure the protocol makes it to the servlet container (this approach was mentioned here. We modify the Tomcat server.xml config in a similar way to get the apache proxy working, too (see here). To ease the process, perhaps the TDS Docker image should allow one to supply their own Tomcat configuration (although I think it sort of does, as the docs hint at it: "Tomcat configuration can be done by mounting over the appropriate directories in In terms of logging, the IP address logged by the TDS is the one passed in by Tomcat via the servlet API. The question is, how do you configure Tomcat to pass along the "correct" IP when nginx is the proxy? We use It looks like everything could be done by adding a special |
|
I found out how to get Thredds to handle the In the I now have the original httpS proto in the URL displayed by Thredds and the original real client IP in my logs. Below are the logs from 1 refresh in the browser: The IP Not sure why Thredds/Tomcat recorded to be hit by the network gateway so much. I would have expected to see the original real client IP or the Nginx proxy IP at all the places we see the network gateway IP. Also it's funny that Thredds logs have the good client IP while the Tomcat logs have the Nginx proxy IP. Will submit a PR for the extra needed Valve line in |
Fixes Unidata/thredds#1310 This should work with the following Nginx proxy config: ``` location /thredds/ { proxy_pass http://thredds:8080/thredds/; proxy_set_header Host $host; # pass the original public hostname to Thredds proxy_set_header X-Forwarded-Proto $scheme; # pass the original httpS proto to Thredds proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # pass the original client IP to Thredds } ```
|
Excellent! Have you ran across this post at https://serverfault.com/questions/514551/make-tomcat-use-x-real-ip? It sounds like you could use <Valve className="org.apache.catalina.valves.RemoteIpValve"
protocolHeader="X-Forwarded-Proto"
remoteIpHeader="X-Forwarded-For"
requestAttributesEnabled="true"
internalProxies="172\.21\.0\.1" />and that would take care of everything you needed, including the IP address in the tomcat logs. |
No did not saw that post, thanks for the reference. That post seems to be applicable to older version of Tomcat.
The fact that the real client IP is not in the Tomcat logs is not too much annoying. The Thredds logs have all the important bits (date time, real client IP, http verb, url path, return code, content lenght). The proposed minimally customized Also, from what I understand, My PR has been declined by the way. Don't know if it's possible to appeal the decision. I've re-explained in the PR why I think the PR is generic and will contribute to the out of the box user experience with Thredds. |
This is our Nginx proxy config. We are using Nginx to provide SSL termination.
We are using docker image
unidata/thredds-docker:4.6.14.What we found out is Thredds is ignoring the
X-Forwarded-Protohttp header and theX-Forwarded-Forhttp header as well since in the logs, we only see IP of our Nginx proxy.Below we see the IP
172.21.0.1which is the Nginx proxy, not the real client IP requesting data from Thredds. It's the same IP everywhere.The original public hostname is preserved by Thredds so the
Hosthttp header seems to be honored properly.To work-around the
X-Forwarded-Protohttp header not being honored, we addedscheme="https"to theConnectorinserver.xml:That
server.xmlfile is from the docker image so we had to insert an entrypoint to modify that file right before the regular startup.We still have no work-around for the wrong client IP being logged because
X-Forwarded-Forhttp header is being ignored.Also, using Nginx as a reverse proxy should be documented here https://www.unidata.ucar.edu/software/tds/current/reference/TomcatBehindProxyServer.html
The text was updated successfully, but these errors were encountered: