Não há muito mais o que fazer além de adicionar o que já foi mencionado nos documentos seu bloco de servidores:
server {
server_name www.example.org;
root /var/www/blog;
...
# add this line (HEAD is implcicit - its a just special case of GET)
limit_except GET POST { deny all; }
...
}
No entanto, não é necessariamente a melhor ideia fazer isso:
Antes de escolher configurar um dos métodos, note a diferença entre 405 e 403 .
- 403 refere-se ao cliente de acesso que não está autorizado a fazer esse pedido.
- 405 refere-se ao servidor não permitindo esse método nessa uri.
Usar uma combinação de ambos é válido: você pode querer dizer aos usuários que o PROPFIND não é permitido aqui, mas quando o cliente tenta PUT ainda diz a ele que, embora possa ser um método entendido, o requisito específico ainda é proibido.
O que você pode configurar com limit_except
é apenas o subconjunto de restrições que pode levar a 403 - não vejo uma maneira de acionar 405 usando limit_except
que seria mais claro do que usar if
imediatamente .
Este é um exemplo (não testado) que combina as respostas 401, 403 e 405 e deve esclarecer sua precendência em uma configuração típica:
server {
listen 192.0.2.1 ssl http2;
server_name example.org;
ssl_certificate_key /etc/ssl/private/example.org.key;
# nobody shall be able to delete anything on this server
if ($request_method = DELETE)
{
# the concerns about using if are not applicable
# if the block only contains "return" or "rewrite .. last"
return 405;
}
root /var/www/html;
location /.well-known {
alias /var/www/well-known;
}
location / {
# logging in from specific IPs grants acces without HBA login
satisfy any;
allow 203.0.113.0/24;
deny all;
auth_basic_user_file /etc/nginx/users.passwd;
auth_basic "join VPN or hit enter on this prompt:";
limit_except GET {
# block does not inherit the access limitations from above
deny all;
}
location /uploading {
limit_except GET POST {
deny all;
}
proxy_pass http://unix:/run/backend.sock:/upload/;
}
}
}
Solicitações de exemplo:
-
O método de solicitação
- DELETE retornará 405
(uma configuração compatível com os padrões deve adicionar um cabeçalho
Allow
, omitido aqui) - OBTER de 203.0.113.0/24 sempre responderá com base em / var / www / html
- PROPFIND de 203.0.113.0/24 retornará 403
- qualquer solicitação de outro cabeçalho de HBA ausente do IP retornará 401
- qualquer solicitação POST com HBA válido fora de / gravável será reencaminhada 403
- mas dentro / gravável, as solicitações POST seriam intermediadas por proxy para o backend As solicitações
- PROPFIND com HBA válido retornarão 403
- qualquer método diferente de DELETE responderá com base em / var / www / well-known