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/reversepro
Dear David & all,
i’ve committed now a version to the main branch of NaviServer on GitHub.
In addition of my last writeup, i’ve further increased the configurability to
make ignoring of non-public servers configurable, no matter whether trusted
severs are configured or not. To ease configuration
Hi Gustaf,
>From your description it sounds like we could certainly work round our
issue using the ReverseProxyTrustedServers config.
Thank you very much for your time on this.
On Fri, 26 Apr 2024 at 14:09, Gustaf Neumann (sslmail)
wrote:
> Hi David,
>
> I have now implemented the following (bu
Hi David,
I have now implemented the following (but not yet committed,
since i was side-tracked by some tcl9 issues and i am running out of
time.
From my understanding, this should address your problems now,
and when “proxy 2” is removed.
An easy extension of this would be to let the site-admin
On Wed, 24 Apr 2024 at 18:53, Gustaf Neumann (sslmail)
wrote:
> This is the case where proxy 1 should not accept the x-forwarded-for
> header from an untrusted upstream server. In case, proxy1 is a nginx
> server, it should use
> proxy_set_header X-Forwarded-For $remote_addr;
> for untrusted upst
> On 23.04.2024, at 18:07, David Osborne wrote:
>
> But the Client can initiate requests which have X-Forwarded-For Headers
> already present, then we run into difficulties
>
> Client: IP 1.1.1.1 : sends X-Forwarded-For: 1.2.3.4
> |
> Proxy 1: sends X-Forwarded-For: 1.2.3.4,1.1.1.1
> Proxy 2:
Thanks,
The situation we were looking at is where NaviServer is behind 2 proxies.
Client: IP 1.1.1.1
|
Proxy 1: sends X-Forwarded-For: 1.1.1.1
|
Proxy 2: sends X-Forwarded-For: 1.1.1.1,2.2.2.2
|
Naviserver: peeraddr -source forwarded = 1.1.1.1
Which is fine.
But the Client can initiate requests
> On 22.04.2024, at 11:01, David Osborne wrote:
>
> In reverseproxymode, when there is a list of IPs in X-Forwarded-For header,
> it's always the leftmost IP which is chosen by NaviServer for accesslogs (and
> ns_conn peeraddr):
>
> X-Forwarded-For 1.1.1.1,2.2.2.2
> ns_conn peeraddr -source
Hi,
In reverseproxymode, when there is a list of IPs in X-Forwarded-For header,
it's always the leftmost IP which is chosen by NaviServer for
accesslogs (and ns_conn peeraddr):
X-Forwarded-For 1.1.1.1,2.2.2.2
ns_conn peeraddr -source forwarded = 1.1.1.1
Is there any mechanism by which we can res
