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 fran...@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
