сервис статические файлы под nginx и Аутентификацией HTTP

Microsoft SQL Server Management Studio Express допускает резервные копии среди всех других вещей, которые она может сделать.

4
задан 2 September 2009 в 08:00
2 ответа

Я не уверен, что Вам нужно

auth_basic off

в областях, на которых Вы не хотите делать аутентификацию. В документах говорится, что это служит для "переопределения действия для наследуемого из директивы низшего уровня", но родительская директива в этом случае (блок сервера) не содержит подлинных директив.

Это может быть ошибка, что, когда Вы пытаетесь отключить наследованную аутентификацию без него, уже быть включенным Вас включает его (возможно, это буквально просто зеркально отражает немного?), но то, что я предложил бы, удаляет тот оператор из Ваших статических местоположений.

Ваше использование ^ ~ на местоположениях ничего действительно не делает насколько я могу сказать, потому что у Вас нет соответствия регулярного выражения в блоке сервера. Если Вы смотрите на описание порядка разрешения здесь:

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

Вы будете видеть, что использование ^ ~ предотвращает проверку местоположения, указанные regex. Далее вниз на той странице документа, Вы будете видеть, что для литеральных соответствий, nginx выбирает "лучшее" соответствие, где "лучше всего" обычно литеральное соответствие с самым долгим соответствием подстроки. То, в чем я не уверен, то, ли внутренне

location /foo

"лучше", чем

location ^~ /foo

даже при том, что оба - литеральные соответствия, последний просто присоединение подсказки. Но так как Вам не нужен ^ ~ бит в Вашей текущей установке, попытайтесь отбросить их и посмотрите, разрешает ли это вещи. Конечно, если Вы дали нам, отредактированная конфигурация для разъясняется, и у Вас действительно есть ~ или ~ * соответствия в Вашем блоке, это не поможет Вам.

Если ничего подобного не работает, то Вы могли попытаться переместиться

auth_basic

и

auth_basic_user_file

операторы в блок сервера. Затем поместите Ваш

auth_basic off

операторы в статические местоположения, где они будут отключать что-то, которое Вы включили.

== ОБНОВЛЕНИЕ ==

Этот простой пример работает на меня под 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;
        }
    }

}

В каталоге сайта все, что я имею, является index.html и графическим файлом в изображениях/. Если я перехожу к /images/filename.jpg на новом сеансе браузера, он подходит без ошибки. Если затем переходят к корню сайта, я получаю подлинную подсказку. Если я затем возвращаюсь к изображению, мой журнал показывает аутентифицируемое имя пользователя (где первый запрос просто показал "-"),

Трассировка пакетов показывает, что подлинная информация предлагалась браузером с ПОЛУЧЕНИЕМ /images/filename.jpg (была проблема № 401). Я предполагаю, что nginx регистрирует предлагаемое имя пользователя, потребовался ли он конкретно, чтобы получать файл или не (и конечно так как проблема была против/, браузер должен предоставить вводимые пользователями учетные данные для /images/filename.jpg).

Очевидно, мой пример не включает проксирование, но основная функциональность там.

Одна ошибка я сделал первоначально проверение этого (который Вы сделали также) состоит в том, чтобы включать подкаталог блока местоположения в корневой директиве. Отметьте, как корень и для изображений / и для / является тем же - nginx, прибавит подкаталог при попытке получить файл.

Если я заставляю корневой параметр для блока изображений / включать изображения/, я получаю 404 попытки добраться до jpg от нового сеанса браузера (не будучи предложенным автора). Интересно, заставляет ли Ваша установка прокси запрос быть пойманным / блок, а не (как в моем примере) проваливающийся нижняя часть конфигурации?

1
ответ дан 3 December 2019 в 04:18
  • 1
    James, I' ve попробовал изменения этого. Моя первая попытка была без auth_basic прочь. Я также попытался изменить порядок блоков местоположения без успеха. –  Ahsan 27 July 2009 в 13:17
  • 2
    Я могу добраться, основная функциональность для работы (посмотрите на раздел под " == ОБНОВИТЕ ==" в ответе) –  James F 27 July 2009 в 18:09
  • 3
    Я попробовал это (удаляющий ^ ~ и удаляющий ' auth_basic off'), но я все еще получаю запрещенные 403... Интересно если it' s проблемы порождения установки прокси... –  Ahsan 28 July 2009 в 11:04
  • 4
    James, я отредактировал свой вопрос... пытался поместить изображения в отдельный блок сервера - провал :( –  Ahsan 2 September 2009 в 07:33

Попробуйте передать ваши файлы пользователю, запускающему nginx (я полагаю, www-data)

0
ответ дан 3 December 2019 в 04:18

Теги

Похожие вопросы