Welcome! Log In Create A New Profile

Advanced

Re: Allow internal redirect to URI x, but deny external request for x?

All files from this thread

File Name File Size   Posted by Date  
smime.p7s 3.5 KB open | download j94305 09/03/2019 Read message
smime.p7s 3.5 KB open | download j94305 09/04/2019 Read message
J. Lewis Muir
August 31, 2019 05:56PM
On 08/31, Francis Daly wrote:
> On Sat, Aug 31, 2019 at 09:10:09AM -0500, J. Lewis Muir wrote:
> > On 08/31, Francis Daly wrote:
>
> Hi there,
>
> > > * starts with /my-app/current/ -> reject
> > > * starts with /my-app/releases/ -> reject
>
> Actually -- those two "rejects" should not be needed.
>
> The app probably should not be installed in the general nginx document
> root directory. The "alias" mentioning the "app/current" directory means
> that that is the only part that nginx will try to serve files from. The
> "root" mentioning the "app/current" directory means that that is the only
> part that nginx will look in (try_files) and mention to the fastcgi server
> (fastcgi_param).
>
> So the "app/releases" directory will not be web-accessible; and the
> "app/current" directory will only be accessible by the explicit url that
> you define.
>
> So the full config should be of the form
>
> location ^~ /app-url/ {
> alias /active-app-dir/;
> location ~ \.php(/|$) {
> root /active-app-dir;
> fastcgi_split_path_info ^/app-url(/.*?php)($|/.*);
> try_files $fastcgi_script_name =404;
> include fastcgi.conf;
> fastcgi_pass unix:php.sock;
> }
> }

I can't believe this! Another great insight! Thank you! I haven't
tried it, but yes, that looks way better, and your observation about not
needing the two rejects puts to rest my incorrect belief that there was
a URI namespace problem with the app directory structure (i.e., with the
"/current/" and "/releases/" URI components). And yes, I will move the
app root out of the nginx document root to avoid the unnecessary risk of
an nginx misconfiguration.

> Adjust regexes based on what you want.
>
> "app-url" can be "my-app". "/active-app-dir" can be "/opt/app/releases/3"
> or "/opt/my-app/current" or anything else.

Got it.

> > Previously, I had the fastcgi_split_path_info call in
> > php-fpm-realpath.conf along with the following file-exists check after
>
> Using "realpath" should not affect nginx at all. nginx invites the
> fastcgi server to use pathname2 instead of pathname1; so the fastcgi
> server is the only thing that should care.

Hmm, I might not be understanding this. The rationale of using
$realpath_root instead of $document_root was to make it so that a
new version of the web app could be deployed atomically at any time
by changing the "current" symlink, meaning that, for example, if the
"current" symlink were changed right in the middle of a request being
handled in PHP, it wouldn't be possible for one part of the request to
execute in PHP in the old version of the app and another part to execute
in the new version. By using $realpath_root, the idea was to ensure
that for any given request being handled in PHP, it would execute in its
entirety in the same version of the web app.

That's why I was doing in php-fpm-realpath.conf

if (!-f $realpath_root$fastcgi_script_name) {
return 404;
}

and

fastcgi_param DOCUMENT_ROOT $realpath_root;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;

So, does that make sense, or am I still not understanding this? I don't
know what you mean by "nginx invites the fastcgi server to use pathname2
instead of pathname1." What are pathname1 and pathname2?

> > For my current app, it doesn't use those URIs, so it's not a problem,
> > but as a general scheme, it's not perfect. I think one solution would
> > be to move the app root directory to a different name so that it can't
> > conflict. For example, have it live at
> >
> > /srv/www/my-app-deployment
>
> As above -- that shouldn't matter. If the app is not deployed in the web
> server document root, only the specific alias/root directory is accessible,
> and the entire url-space below that is available.

Understood.

> (And you can have one url prefix /my-app/, and a separate url prefix
> /my-app-prev/, which uses the next most recent version. Restrict access
> to that location{} to your source IP address, and you can do regression
> testing between the two.)
>
> > or something like that. Then I could just return a 404 for any request
> > on that, e.g.:
> >
> > location ^~ /my-app-deployment/ {
> > return 404;
> > }
>
> If you don't want nginx to serve content from the my-app-deployment
> directory, it is probably easier for it to be somewhere other than
> /srv/www.
>
> It is hard to misconfigure nginx in that case.

Agreed; I will move it out of there.

Thank you!

Lewis
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 30, 2019 01:34PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 30, 2019 02:22PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 30, 2019 02:38PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 30, 2019 03:00PM

Re: Allow internal redirect to URI x, but deny external request for x?

Francis Daly August 30, 2019 04:56PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 30, 2019 06:00PM

Re: Allow internal redirect to URI x, but deny external request for x?

Francis Daly August 30, 2019 07:22PM

Re: Allow internal redirect to URI x, but deny external request for x?

Francis Daly August 31, 2019 03:28AM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 31, 2019 11:06AM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 31, 2019 10:12AM

Re: Allow internal redirect to URI x, but deny external request for x?

Francis Daly August 31, 2019 04:52PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 31, 2019 05:56PM

Re: Allow internal redirect to URI x, but deny external request for x?

Francis Daly September 02, 2019 05:04PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir September 03, 2019 01:28PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir September 03, 2019 05:32PM

Re: Allow internal redirect to URI x, but deny external request for x?

Ian Hobson August 30, 2019 03:02PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir August 31, 2019 11:32AM

Re: Allow internal redirect to URI x, but deny external request for x?

Francis Daly August 30, 2019 04:34PM

Re: Allow internal redirect to URI x, but deny external request for x?

gariac August 30, 2019 05:24PM

Re: Allow internal redirect to URI x, but deny external request for x?

Ian Hobson August 31, 2019 10:42AM

Re: Allow internal redirect to URI x, but deny external request for x?

j94305 August 30, 2019 06:28PM

Re: Allow internal redirect to URI x, but deny external request for x?

gariac August 31, 2019 03:20PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir September 03, 2019 11:30PM

Re: Allow internal redirect to URI x, but deny external request for x? Attachments

j94305 September 03, 2019 11:56PM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir September 04, 2019 11:30AM

Re: Allow internal redirect to URI x, but deny external request for x? Attachments

j94305 September 04, 2019 11:44AM

Re: Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir September 04, 2019 12:32PM

Re: Allow internal redirect to URI x, but deny external request for x?

j94305 September 10, 2019 02:46PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 63
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready