Hi, @storefront. We can meet some of those requirements but not all of them.
- We would require “X-Forwarded-For” header with the Client IP
That header is sent and it contains several IP addresses one of which is the client IP address. There is a different header which contains just the client IP address which is the x-nf-client-connection-ip header.
Also, the other IP addresses in the X-Forwarded-For header which are not the client IP address will be in reserved IP address ranges. This means it is very easy to determine which IP addresses are not the client IP address. In other words, if you filter that list to remove the reserved IP addresses then the client IP address will be the only one that remains.
- We would require the IP range of the proxy provider, to use the same on Wordpress as per the doc for security reasons.
The IP addresses used for proxying will be the IP address of the individual CDN nodes. Those IP addresses are not in single network block and are also continually changing. We do not provide a static IP address list for the IP addresses is used for CDN nodes.
In other words, there is no list of IP addresses I can give you today which you can be guaranteed will work tomorrow. I could give you a list today but it can change at any time and without notice (and it would likely change in days not weeks). Because it will change so quickly we do not attempt to provide a list at this time. If we did so it would almost certainly create confusion that there is a static IP address list (there is not) and we don’t want to cause that misunderstanding.
There is a feature request for a static IP addresses list to be used for proxying. (There is another feature request for static IP addresses to be used by the build system for outbound HTTP requests.) Again, though, this isn’t possible at this time.
- Can we pass custom header as per this doc (Custom headers | Netlify Docs) & pass dynamic value (like client ip which you can share via pre-defined variables / pointing to custom environment variable, etc… ?)
You can pass static custom headers using the custom headers in proxy redirects instructions. So, if you have an environment variable defined you can use that at build time to hardcode that value into the redirects for that specific deploy. It will not be dynamic though.
For example, if you were to set the value in the header using an environment variable during the build and then triggered a new build the value would be used. However, if you now change that environment variable but don’t trigger a new build, the value from the previous deploy will continue to be used. Only once there was a new successful deploy would the new value be used. That is because the build code would be responsible for setting this value as a static value during the build itself.
Note, that “the build code would be responsible” phrase above. This means that (for example) environment variables placed in _redirects, _headers, or netlify.toml (the three places you can define headers), are not automatically evaluated. You could manually rewrite those file during the build however to replace text placeholders with the environment variable value using sed in the build command. There is an example in this post quoted below:
There are probably a million ways, but when I need to populate a file with a value, I do something like this in my build command:
sed -i s/PLACEHOLDER/${VARIABLENAME}/g webpack.js && my-usual-build-commandThis way the value is put in place in the file before I need it. I don’t know how webpack runs things in its config file while you use it, so there may be a more elegant way but it comes back down to “populate the value in a file before you need it”.
The find and replace above is in a javascript file but the same can be applied to any text files being used during the build - _redirects, _headers, and netlify.toml included. This will allow you to hard code environment variables into headers or redirect rules at build time.
There is also a workaround which is that you can use a function to proxy. Instead of the default proxying our service provides, you could do this instead:
- direct the path to a function
- the function then created the dynamic header and makes the proxied request
- the function then returns the proxied content as its own response
In other words, you proxy via a function. Then your function creates and sends the dynamic header when making its HTTP request to the proxy target.
If there are other question, please let us know.