You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We had a new situation crop up where a specific agency subdomain needed had another proxy in front of our api.data.gov service. This meant that by default, we were treating all of the traffic as though it was coming from this other proxy's IP. This in turn would skew our analytics and rate limiting, since all of the traffic would appear to come from just a couple IPs (the proxy IPs), rather than the real IPs used by the clients.
In order to fix this, we need to be able to read the original client's IP address from a different HTTP header. Normally, we read this information from the X-Forwarded-For HTTP header, and we configure which servers we trust this forwarded information from. However, for this specific case, we need to read this information from the True-Client-IP header.
The text was updated successfully, but these errors were encountered:
This doesn't expose this functionality within the admin, but does give us a way to manually configure this behavior on a per-host basis with our hosts configuration (so api.data.gov server admins can make this tweak). We're basically just exposing a way to configure nginx's realip module for individual hosts. The various settings can be tweaked to adjust which HTTP header is used, and how to trust this header based on its origin. Since the realip module directly hooks into nginx's IP handling, this propagates everywhere else we need within the app, since it automatically affects the IP we read everywhere else (for logging, rate limiting, and appending to our own X-Forwarded-For).
We had a new situation crop up where a specific agency subdomain needed had another proxy in front of our api.data.gov service. This meant that by default, we were treating all of the traffic as though it was coming from this other proxy's IP. This in turn would skew our analytics and rate limiting, since all of the traffic would appear to come from just a couple IPs (the proxy IPs), rather than the real IPs used by the clients.
In order to fix this, we need to be able to read the original client's IP address from a different HTTP header. Normally, we read this information from the
X-Forwarded-For
HTTP header, and we configure which servers we trust this forwarded information from. However, for this specific case, we need to read this information from theTrue-Client-IP
header.The text was updated successfully, but these errors were encountered: