Thanks again Gustaf.
I've been running some tests and it's looking good.
There's one case I'm not sure this can cater for, and this is probably more
of an issue in development environments...
When the trusted cidr is a subnet which also contains the client.
Say
ns_section ns/parameters/reverseproxymode {
ns_param enabled on
ns_param trustedservers {192.168.0.0/16}
ns_param skipnonpublic false
}
And Client IP = 192.168.0.10 with a proxy on 192.168.0.200
I think NaviServer will skip all addresses which appear in the trusted
subnet:
Do you think it would be appropriate to have this behaviour as configurable?
Option 1. Strict.
If the header is from a peer on the trusted list - return only the entry
our trusted peer added (regardless of whether that entry is, in turn, also
in the trusted subnet).
ff {192.168.0.11,192.168.0.10} key 0-1 peer 192.168.0.200 forwarded
{192.168.0.10}
Option 2. Greedy.
If the header is from a peer on the trusted list - return the first
untrusted entry searching from the right
ff {192.168.0.11,192.168.0.10} key 0-1 peer 192.168.0.200 forwarded {}
(I think this is why Nginx introduced the "real_ip_recursive" option on
their real_ip module for instance.)
https://nginx.org/en/docs/http/ngx_http_realip_module.html
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
