Mathew Davies wrote:
>
> A more efficient way of doing this is :
>
>
> I do not see why. I am specifying "return 403" 3 times vs once. I was
> it doing it this way before and did not think it was so efficient.
When referring to 'efficient' I'm talking about the speed at which the
statements are processed by Nginx. Sorry if that wasn't clear.
>
> Here is my full config
>
> server {
> listen 80;
> server_name ---;
> root /home/website/www/---/public/;
> index index.php index.html index.htm;
>
> # Logs
> access_log /home/website/www/---/log/access.log combined;
> error_log /home/website/www/---/log/error.log warn;
>
> # Protect certain directories.
> location ~* ^/(library|conf|appg) {
> return 403;
> }
>
> # Cache forum assets for as long as possible.
> location ~* \.(css|js|gif|ico)$ {
> expires max;
> add_header Cache-Control private;
> break;
> }
>
> location ~* \.php$ {
> fastcgi_pass 127.0.0.1:9000 http://127.0.0.1:9000;
> fastcgi_index index.php;
> fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
> include fastcgi_params;
> }
> }
>
What's the URL you're having problems with and which location is it
matching too? Since all the locations are regexes, I would have thought
that they would be processed in order - though I'm not sure if they are
somehow re-ordered according to certain matching priorities (though I
doubt it).


Using

location ^~ /library {
return 403;
}

location ^~ /conf {
return 403;
}

location ^~ /appg {
return 403;
}

will guarantee that they are processed (and matching halted) before
processing any regexes though, which is probably a good reason to put
them in that format anyway (if you change the ordering of your regexes,
then this might change the location they are matched to).

Marcus.