Define a proxy for Nginx

[António P. P. Almeida]

As for the first point, of course that variable needs to be used on the
application side.
The OP suggested that is cased since he described basically that with the
Apache env var
directive.

As for  the second, I was not considering security issues, but:

1. You need to be able to edit the php-fpm configuration.

2. You need to do a reload for the config to take effect.

In a properly setup Nginx both of these require *root* access.

Yes it's hardly the best way to do things. But then it works and it isn't
either the worst.

Note that it's not a header at all, but a parameter passed through the FCGI
daemon on each
request.

----appa



On Wed, Nov 6, 2013 at 10:24 AM, Jonathan Matthews
<contact at jpluscplusm.com>wrote:

> On 5 November 2013 15:25, António P. P. Almeida <appa at perusio.net> wrote:
> > Assuming you're using php-fpm or php-cgi you can set a param to pass
> that as
> > a server variable:
> >
> > fastcgi_param HTTP_PROXY 'http://proxy:myport';
> >
> > Then you'll have a $_SERVER['HTTP_PROXY'] entry for the global $_SERVER.
>
> I don't think this is right, for a couple of reasons.
>
> Firstly, some reading has suggested that there isn't a way to force
> the stock PHP HTTP request libraries to use a proxy just by setting an
> envvar. Witness, for instance, the code-level changes that are
> (/were?) required to get a relatively mainstream piece of s/w like WP
> to work with an outbound proxy:
> http://wpengineer.com/1227/wordpress-proxysupport/
>
> Secondly, the specific string mentioned would (unless I'm missing
> something, which is very possible!) open a security hole: $_SERVER
> contains all user-specified HTTP request headers with added "HTTP_"
> prefixes. The method suggested, if it worked, would mean that, as a
> user, I could simply provide a "Proxy: my.proxy.server.ip" header and
> get all outbound HTTP traffic (for my request) proxied via *my*
> external server. Thereby exposing internal information such as 3rd
> party API passwords, internal HTTP API call details, etc etc.
>
> Again, I may be missing something with either of these points but,
> obviously, I don't see what it might be! :-)
>
> Regards,
> Jonathan
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20131106/a0393df1/attachment.html>