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

[Francis Daly]

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;
    }
  }


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.

> I changed the root directive to come before the fastcgi_split_path_info,
> but that was just aesthetic; it worked fine the other way
> too.

Yes. For many directives in nginx, the order in the config file does
not matter.

("rewrite" module directives use the order. And regex locations use
their order. I think that most others do not. Your fastcgi server might
care about the order that the fastcgi_param directives had, but nginx
does not.)

>  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.

> 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.

(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.

Cheers,

	f
-- 
Francis Daly        francis at daoine.org