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

[J. Lewis Muir]

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