Não tenho certeza se você precisa
auth_basic off
nas áreas em que você não deseja fazer autenticação. Os documentos dizem que isso serve para "substituir a ação pela herdável de uma diretiva de nível inferior", mas sua diretiva pai neste caso (o bloco de servidor) não contém nenhuma diretiva de autenticação.
Pode ser um bug que, quando você tenta desabilitar a autenticação herdada sem que ela já esteja habilitada, a ativa (talvez esteja apenas invertendo um pouco?), mas o que eu sugiro é remover essa afirmação de seus locais estáticos .
Seu uso de ^ ~ nos locais não está realmente fazendo nada, tanto quanto eu posso dizer, porque você não tem nenhuma expressão regular correspondente no bloco do servidor. Se você observar a descrição do pedido de resolução aqui:
Você verá que o uso de ^ ~ impede a verificação de locais especificados por regex. Mais abaixo nessa página do documento, você verá que, para correspondências literais, o nginx escolhe a "melhor" correspondência, em que "melhor" geralmente é a correspondência literal com a correspondência de substring mais longa. O que eu não tenho certeza é se internamente
location /foo
é "melhor" que
location ^~ /foo
embora ambos sejam correspondências literais, o último apenas tem uma sugestão anexada. Mas desde que você não precisa do bit de ~ em sua configuração atual, tente derrubá-los e ver se isso esclarece as coisas. É claro que, se você nos der uma configuração redigida para esclarecer e tiver correspondências ~ ou ~ * no seu bloco, isso não ajudará você.
Se nada disso funcionar, você pode tentar mover o
auth_basic
e
auth_basic_user_file
instruções para o bloco do servidor. Então coloque seu
auth_basic off
declarações nos locais estáticos, onde eles estarão desativando algo que você ativou.
== UPDATE ==
Este exemplo simples funciona para mim sob 0.7.61:
server {
listen 80;
server_name test.domain.com;
access_log /var/log/nginx/sites/test.domain.com/access.log;
error_log /var/log/nginx/sites/test.domain.com/error.log;
location /images {
root /srv/www/sites/test.domain.com;
}
location / {
root /srv/www/sites/test.domain.com;
index index.html;
auth_basic test;
auth_basic_user_file /etc/nginx/auth/test.htpasswd;
if ( -f $request_filename ) {
expires 30d;
break;
}
}
}
No diretório do site, tudo que eu tenho é index.html e um arquivo gráfico em / images. Se eu for para /images/filename.jpg em uma nova sessão do navegador, ele aparece sem erros. Se, em seguida, ir para a raiz do site, recebo um prompt de autenticação. Se eu retornar à imagem, meu log mostrará o nome de usuário autenticado (em que a primeira solicitação acabou de mostrar "-")
Um rastreamento de pacote mostra que a informação de autenticação foi oferecida pelo navegador com o GET de /images/filename.jpg (não houve desafio 401). Eu assumo que o nginx registra um nome de usuário oferecido se foi especificamente necessário para obter o arquivo ou não (e, claro, como o desafio era contra /, o navegador deve fornecer credenciais inseridas pelo usuário para /images/filename.jpg).
Obviamente, meu exemplo não inclui proxy, mas a funcionalidade básica está lá.
Um erro que cometi inicialmente ao testar isso (o que você fez também) é incluir o subdiretório do bloco de localização na diretiva raiz. Note como a raiz para ambos / images e / são os mesmos - o nginx irá adicionar no subdiretório ao tentar recuperar o arquivo.
Se eu fizer o parâmetro root para o / images block include / images, recebo um 404 tentando acessar o jpg de uma nova sessão do navegador (sem ser solicitada a autenticação). Gostaria de saber se sua configuração de proxy está fazendo com que o pedido seja capturado pelo bloco / em vez de (como no meu exemplo) cair na parte inferior da configuração?