[PATCH] Added $realip_add_x_forwarded_for
Maxim Dounin
mdounin at mdounin.ru
Mon May 22 12:48:23 UTC 2023
Hello!
On Sun, May 14, 2023 at 04:51:58AM +0100, J Carter wrote:
> # HG changeset patch
> # User jordanc.carter at outlook.com
> # Date 1684035158 -3600
> # Sun May 14 04:32:38 2023 +0100
> # Node ID dad6e472ee0d97a738b117f6480987ef135c9e7f
> # Parent b71e69247483631bd8fc79a47cc32b762625b1fb
> Added $realip_add_x_forwarded_for
>
> Resolves Ticket #2127.
>
> Duplicates the functionality of proxy_add_x_forwarded_for, except
> the true source ip is appended and not the remote address extracted
> by the real IP module.
>
> In practice this is proxy_add_x_forwarded_for but $realip_remote_addr
> is used and not $remote_addr.
>
> This follows the same convention as $realip_remote_addr and
> $real_ip_remote_port, in that it is a drop in replacement for
> $proxy_add_x_forwarded_for that can be used in contexts that both do
> and do not have the real_ip directives, with the same results.
>
> An example configuration:
>
> server {
> listen 80;
> real_ip_header X-Forwarded-For;
> set_real_ip_from 127.0.0.1;
>
> location / {
> proxy_set_header X-Forwarded-For $realip_add_x_forwarded_for;
> proxy_set_header Remote $remote_addr;
> proxy_pass http://127.0.0.1:8080;
> }
> }
Thanks for the patch, but I can't say I like the idea of
introducing yet another variable and asking users to change it
manually. This is essentially equivalent to using
proxy_set_header X-Forwarded-For "$http_x_forwarded_for, $realip_remote_addr";
as the ticket suggests.
Also, it is an open question if $realip_remote_addr should be
used, or X-Forwarded-For should be left unmodified if remote addr
was set from X-Forwarded-For. The realip module instructs nginx
to use the address as obtained from the header, and not using it
for some purposes looks at least questionable.
Also, it seems incorrect to use $realip_remote_addr (or keep
X-Forwarded-For unmodified) if remote addr was set from other
sources, such as PROXY protocol headers.
Overall, current behaviour might actually be optimal.
[...]
--
Maxim Dounin
http://mdounin.ru/
More information about the nginx-devel
mailing list