Denying access to pico's internal files

[ohnonot]

About this section of nginx setup recommendations.

I find that if I set it up this way, then try to open one of the forbidden places, pico offers index.php as a download instead of going to the 404 page (the 404 page works well for other non-existing pages).

Taking the example configuration as a basis, I changed it like this:

server {
	listen 80;

	server_name www.example.com example.com;
	root /var/www/html/pico;

	index index.php;

	error_page 404 /404;
	error_page 403 =404 /404;

	location ~ ^/((config|content|vendor|composer\.(json|lock|phar))(/|$)|(.+/)?\.(?!well-known(/|$))) {
		return 404;
	}

	location ~ \.php$ {
		try_files $uri =404;

		fastcgi_pass unix:/var/run/php5-fpm.sock;
		fastcgi_index index.php;
		include fastcgi_params;

		# Let Pico know about available URL rewriting
		fastcgi_param PICO_URL_REWRITING 1;

		# my nginx/php-fpm combo won't work without this:
		fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
	}

	location / {
		try_files $uri $uri/ /index.php$is_args$args;
	}
}

...which gives the desired result.
It also appears safer to me, because ultimately I am giving control over these forbidden places back to nginx, and not letting pico deal with it?

---

I am a little unsure if this is a documentation issue or an issue with pico itself or with my setup...
If it helps, my nginx is at version 1.10.3, what is current in debian stable.
php-fpm recently upgraded from 5 to 7.
pico 2.0.4.

[PhrozenByte]

Letting Pico handle requests to Pico's internal files like config is neither more nor less secure than passing it to nginx; the only difference is that the latter exposes the existence of these directories, because they are treated differently than any other non-existing files/dirs.

Not sure why you were experiencing this issue; did you try removing the error_page directive? Configuring nginx is a very extensive subject and you often get unexpected results.

[ohnonot]

did you try removing the error_page directive?

yes, i did.
Set up as above, it will give me generic 404 messages.
If however I use try_files /index.php$is_args$args =404; (as in the config example) instead of return 404;, i'm back at the strange behavior of being offered index.php to download.
I have been shifting around the location blocks and trying things for another hour or so, I can't get to the bottom of it.

The way it is now works well for me; I'd just like to understand why it doesn't work as per documentation. Does it work for you?

[PhrozenByte]

Unfortunatly I'm not using nginx and don't have much experience with it, the nginx docs were written by @smcdougall. However, at the time of writing, it worked as expected. No idea what's wrong there 😒

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! 👍