i file statici di servizio in nginx & HTTP-Authentication

Ho un'applicazione distribuita in modalità di test su un server. L'accesso a esso è stato limitato a un gruppo selezionato di utenti tramite l'authentication HTTP. Che funziona bene. Il problema è che, se servo file statici tramite una diversa direttiva 'location', nginx mi dà un "non autorizzato" per questi file. Ho provato auth_basic off, ma nessun dado.

Ecco il vhost conf:

# Virtual Host upstream appname { server 127.0.0.1:4000; server 127.0.0.1:4001; server 127.0.0.1:4002; } server { listen 80; server_name appname.domain.com; # write app specific log # make sure you create this file in your log directory before running behind nginx access_log /home/apps/appname/shared/log/nginx.log main; # let nginx serve static files directly # images location ^~/images { auth_basic off; root /home/apps/appname/current/public/images; } location ^~/covers { auth_basic off; root /home/apps/covers; } # # javascript location ^~/javascripts { auth_basic off; root /home/apps/appname/current/public/javascripts; } # # css location ^~/stylesheets { auth_basic off; root /home/apps/appname/current/public/style; } # Push all other requests to Merb location / { # needed to forward user's IP address to merb proxy_set_header X-Real-IP $remote_addr; auth_basic "domains"; auth_basic_user_file htpasswd; if (!-f $request_filename) { proxy_pass http://appname; break; } } } 

Eventuali suggerimenti ?

EDIT:

Ho provato a mettere le immagini sotto un altro sottodominio e configurare un block "server" separato per questo – senza alcun http_auth. Ma mi dà ancora un 403 proibito all'image! Ecco quello che ho aggiunto:

 server { listen 80; server_name images.domain.com; access_log /home/apps/appname/shared/log/nginx_images.log main; error_log /home/apps/appname/shared/log/nginx_images_error.log; error_page 500 502 503 504 /500.html; location = /500.html { root /home/apps/www/http_error_codes; } location /images { root /home/apps/appname/current/public/images; } location /covers { root /home/apps/covers; } open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; } 

Ho anche cercato di aprire un nuovo browser e di accedere a un file di immagini direttamente da images.domain.com, ma ancora dice 403 vietato!

  • Ottimizza linux per la pubblicazione di contenuti statici http
  • Strani Bittorrent Accedi al mio server
  • Imansible get Nginx per servire la catena del certificato corretto
  • nginx stop / reload nelle windows non riuscite per l'accesso è negato
  • NGINX restituisce le intestazioni corrette con documenti di errore personalizzati
  • Come controllare la configuration nginx ma senza copiare il nuovo file di configuration nella directory nginx?
  • nginx e vernice per la memorizzazione della cache forzante ssl
  • Creazione di una pagina di errore fallback per nginx quando la directory principale non esiste
  • 2 Solutions collect form web for “i file statici di servizio in nginx & HTTP-Authentication”

    Non sono sicuro di aver bisogno

     auth_basic off 

    nelle aree in cui non si desidera eseguire l'authentication. I docenti affermano che questo serve a "superare l'azione per l'inheritance; da una direttiva a livello più basso", ma la tua direttiva genitore in questo caso (il block server) non contiene alcuna direttiva di authorization.

    Può essere un bug che quando si tenta di disabilitare l'authentication ereditaria senza che sia già abilitata, lo si accende (forse è letteralmente solo un po 'fottuto), ma quello che suggerisco è la rimozione di quella dichiarazione dalle posizioni statiche.

    Il tuo uso di ^ ~ nelle posizioni non sta realmente facendo nulla per quanto posso dirlo, perché non hai alcuna corrispondenza regolare corrispondente nel block server. Se si guarda qui alla descrizione dell'ordine di risoluzione:

    http://wiki.nginx.org/NginxHttpCoreModule#location

    Vedrai che utilizzando ^ ~ impedisce di controllare le posizioni specificate da regex. Ancora più in basso su quella pagina doc, vedrai che per le partite letterali, nginx sceglie la partita "migliore", where "meglio" è generalmente la corrispondenza letterale con la corrispondenza più lunga di substring. Quello che non sono sicuro di se sia internamente

     location /foo 

    è meglio di

     location ^~ /foo 

    anche se entrambe sono partite letterali, quest'ultimo solo avendo un suggerimento allegato. Ma poiché non hai bisogno del bit ^ ~ nella configuration corrente, prova a abbassarli e vedere se elimina le cose. Naturalmente, se ci hai dato una configuration redatta per chiarire e hai delle partite ~ o ~ * nel tuo block, questo non ti aiuterà.

    Se nessuno di questi funziona, allora si potrebbe provare a spostare la

     auth_basic 

    e

     auth_basic_user_file 

    dichiarazioni nel block server. Poi metti il ​​tuo

     auth_basic off 

    nelle posizioni statiche, in cui distriggersno qualcosa che hai triggersto.

    == UPDATE ==

    Questo semplice esempio funziona per me sotto 0.7.61:

     server {
    
         ascoltare 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;
    
         posizione / immagini {
             radice /srv/www/sites/test.domain.com;
         }
    
         luogo / {
             radice /srv/www/sites/test.domain.com;
             index index.html;
    
             test auth_basic;
             auth_basic_user_file /etc/nginx/auth/test.htpasswd;
    
             se (-f $ request_filename) {
                 scade 30 giorni;
                 rompere;
             }
         }
    
     }
    

    Nella directory del sito, tutto quello che ho è index.html e un file grafico in / images. Se vado a /images/filename.jpg in una nuova session di browser, viene senza errori. Se poi vai alla radice del sito, ottengo un prompt di authorization. Se return all'image, il mio registro mostra il nome utente autenticato (where la prima richiesta ha mostrato solo "-")

    Una traccia di pacchetti mostra che le informazioni sull'authorization sono state offerte dal browser con il GET di /images/filename.jpg (non c'era sfida 401). Suppongo che il filename fosse un nome utente offerto se fosse stato specificamente richiesto di get il file o no (e naturalmente dato che la sfida era contro /, il browser deve fornire le credenziali immesse dagli utenti per /images/filename.jpg).

    Ovviamente il mio esempio non include proxying, ma la funzionalità di base è lì.

    Un errore che ho fatto prima di verificare questo problema (quello che hai fatto pure) include la sottodirectory del block di posizione nella direttiva root. Notare come la radice per entrambe le immagini / e / sono uguali – nginx aggiungerà alla sottodirectory quando si tenta di recuperare il file.

    Se faccio il parametro radice per il block / images include / images, ottengo un 404 cercando di arrivare al jpg da una nuova session del browser (senza richiedere l'authorization). Mi chiedo se la configuration del proxy sta causando la richiesta di essere bloccata dal / block piuttosto che (come nel mio esempio) che cade nel fondo della configuration?

    Provare a bloccare i file per l'utente che esegue nginx (dati www-suppongo)

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.