Nginx auth basic не работает

Базовая аутентификация в nginx. Закрываем админку магазина

На страницах блога мы уже не первый месяц работаем с админками. Сделали простую админку на файлах и пилим админку интернет-магазина на vue.js. И все у нас хорошо, кроме того, что наши админки доступны всему интернету. Для тестового магазина в бложике это гордость, а для реального проекта — наоборот.

Это проблема авторизации в веб-приложениях и рано или поздно программисты с ней сталкиваются. Каждый решает это по-разному. В золотые времена фриланса я уверенно закрывал страницы через body < display: none >и это работало. Сейчас так просто уже не получится, приходится читать гуглы и делать технологии.

Когда задумываешься об авторизации первый раз, то хочется сразу сделать красиво. Форма регистрации и логина, хранение паролей в базе данных, естественно, в зашифрованном виде, подтверждение регистрации письмом на почту с уникальной ссылкой, восстановление и возможность смены пароля. А может даже двухфакторная аутентификация или регистрация через соц сети. Много всего. Любой клиент будет рад таким возможностям, да и самому приятно делать сразу и хорошо.

Но есть момент — не всегда это стоит времени и усилий.

Возможно, вы делаете проекты на готовых CMS или фреймворках, где авторизация уже реализована за нас. Разные modx, drupal и laravel по умолчанию дают все, что я перечислил, и даже больше. Не нужно думать и изобретать свое.

Но иногда приходится делать авторизацию, а для мелкого лендинга не хочется ставить даже modx. Например, на сайте всего одна страница. Клиент хочет сам менять телефон, почту и цены. Ставить CMS? Чот неохота. Да и нужно перейти на тариф повыше, где поддерживаются БД. Вот поди объясни владельцу конторы пластиковых окон, за что платить лишние 30 долларов в год? Он у тебя сайт заказал, а не какие-то там базы данных!

Для таких сложных ситуаций «клиент жлоб, а я ленивый» есть выход — подключаем нашу простую файловую админку и закрываем ее через базовую аутентификацию. Что это вообще такое?

Basic Http Authentification придумали как раз для того, чтобы быстро закрывать сайты или их отдельные разделы от посторонних глаз. Поддерживается эта штука практически всеми браузерами и работает адекватно при условии, что ваш сайт на https. На http-сайтах закрывать админки через basic auth не стоит, потому что логин и пароль передаются в http-заголовках в открытом виде. А значит вас могут поломать злые хакеры.

Сейчас мы рассмотрим, как подключить basic auth на админке интернет-магазина. Работать будем на Linux Mint и nginx. Материал нагуглен здесь

Подключаем basic auth

Общая схема работы такова: создадим файлик .htpasswd с логином и паролем, а в конфигах nginx укажем путь к этому файлику и какой сайт или директорию нужно закрыть. Звучит просто, делается тоже несложно.

Сначала нужно установить утилитки, которые помогут сгенерить .htpasswd

Теперь можно уже создать нужный файл

Флажок -c указываем, когда только создаем .htpasswd, /etc/nginx/conf.d/.htpasswd — путь к файлику, а admin — нужный логин.

Эта команда предложит ввести пароль для пользователя admin

Когда введете пароль, то сгенерится файлик с примерно таким содержимым

Это пароль admin_password, никому не рассказывайте.

Дальше идем в конфиги nginx

w-shop.lc, это у меня так смешно называется интернет-магазин. Давайте сначала попробуем закрыть его целиком. В разделе server конфига добавим 2 строки

Тупо строка приветствия и путь к файлу. Полный конфиг у меня получился такой

Дальше перезапускаем nginx

И заходим на любую страницу магазина w-shop.lc. Видим такое окошко. Кстати, у меня сайт на домашнем ноутбуке, естественно, без https. Поэтому хром об этом предпреждает, умница. Your connection is not private.

Кстати, если у вас открылся сайт без окошка авторизации, то просто страница сохранилась в кеше браузера. Перезагрузите страницу с Ctrl+Shift+R или Cmd+R и увидите приглашение залогиниться. Работает.

Закрываем отдельную папку

Теперь интереснее. Давайте сам сайт откроем, а закроем только админку. Напомню, она лежит в папке /admin/vue. Чтобы закрыть только эту папку, нужно чуть поправить конфиг nginx. Убрать те 2 строчки выше и добавить новый location

Вот и все. Еще раз перезапускаем nginx, пробуем зайти в сам магазин и админку — видим, что закрыта только админка.

Если вам зачем-то понадобилось добавить нового пользователя с другим паролем, то нужно еще раз вызвать утилиту htpasswd, только без флага -с (create — файл уже создан, второй раз его не создать)

И не забыть перезапустить nginx. Теперь у нас 2 пользователя.

Плюсы и минусы базовой аутентификации

Из плюсов: простота и нативность реализации. Делается парой команд и обеспечивается средствами браузера.

Из минусов. Первое, не каждый хостинг-провайдер позволит править конфиги веб-сервера. Второе, не гибко. Пользователи добавляются руками, чтобы изменить пароль, нужно пересоздать файлик. Я видел код на php, который вытаскивает логины-пароли из базы и подставляет в basic auth, но не проверял. Думаю, заморачиваться с этим не стоит. Если у вас пользователи добавляются динамически, то все равно вам придется делать обвязку, создавать их, удалять, менять пароли, а это уже близко к полноценной системе авторизации.

Когда стоит использовать basic auth

По мне, ее стоит применять в двух случаях.

Первое, при разработке проекта, чтобы скрыть от посторонних глаз целый сайт или отдельный раздел.

Второе, в простой админке вроде упомянутого примера с лендингом.

Для админки небольшого интернет-магазина basic auth подходит. Для личного кабинета — уже нет. Там работать с пользователями нужно тоньше. Хранить пользователей в базе, реализовывать интерфейс для регистрации, логина/разлогина и изменения-восстановления пароля. Разобраться с механизмом работы сессий и подумать, как безопасно хранить пользовательские данные, а особенно, пароли. Но это уже совсем другая история.

Источник

Auth_basic и proxy_pass в Nginx

Наблюдаю какую-то нелогичное поведение при использовании auth_basic
Мне нужно временно закрыть доступ к главной аутентификацией, при этом всё остальное закрывать не нужно
Конфиг:

Почему то при каждом обращении к /api возникает запрос аутентификации, даже если добавить там явно auth_basic off
Гугл находит аналогичную проблему без решения
https://serverfault.com/questions/796028/nginx-proxy-pass-and-auth-basic-prom.

Попробуй вынести auth* выше, за пределы location, а в /api добавить auth_basic off.

Добавь к location /api
satisfy any;

Почему-то не помогло

Тоже не помогло, ничего не понимаю

А если добавить в /api

Да, на вид работает, наконец догадался посмотреть дамп и там действительно был этот заголовок в сторону апстрима, завтра потестирую поплотнее
Но, ска, как так, что за танцы с бубнами?!

tiandrey , Холмс, у нас новое дело

Ну, собственно, всё логично.

Пользователь идёт на главную, получает запрос авторизации, авторизуется. И дальше заголовок авторизации суёт во все запросы к этому домену. И пока он не попадает на /api , всё хорошо — фронтовый веб-сервер эту аутентификацию обрабатывает, и пользователю данные отдаёт.

Но вот пользователь идёт на url /api/xxx , и его браузер всё так же отправляет заголовок Authorization . Добрый nginx все заголовки клиента, кроме запрещённых, передаёт в апстрим. И уже апстрим ругается на эту пару логин-пароль и требует повторной авторизации (не очень очевидное поведение апстрима, кстати говоря). Ну а с помощью proxy_set_header Authorization «»; ты просто запрещаешь передавать заголовок Authorization апстриму.

Проверить это предположение можно, открыв при старой конфигурации в порнорежиме на твоём сайте урл с /api .

Ну и это, не стесняйся в nginx debug-лог включать, там бы ты сразу увидел, что у тебя апстрим авторизацию просит, а не фронтовый веб-сервер.

Но почему не срабатывает auth_basic off? Вот что меня больше всего добивает.
На моём окружении nginx к сожалению собран без debug и заменить нельзя

Но почему не срабатывает auth_basic off? Вот что меня больше всего добивает.

Запрос аутентификации приходит не от фронтового nginx’а, а от апстрима, насколько я понимаю.

На моём окружении nginx к сожалению собран без debug и заменить нельзя

Чо, даже в хомяк залить бинарник с дебагом нельзя?

Бинарник поищу, но дистрибутив старый, под него непросто что-то найти

Будь мужиком, собери сам, блеать! Там ничего особого для сборки не требуется.

Источник

Настройка auth basic Nginx

Даже если вы ещё не знаете что такое Basic Auth, вы наверняка уже с ней сталкивались, например, при входе в интерфейс настройки роутера. Это механизм авторизации по имени пользователя и паролю на уровне веб-сервера. Такая авторизация поддерживается и в Apache и в Nginx.

В этой статье мы разберемся как настроить Basic Auth Nginx, для определённого маршрута или для всего сайта.

Настройка Basic Auth в Nginx

Окно авторизации Basic Auth выглядит вот так:

Думаю теперь вы знаете о чём идёт речь. Такую авторизацию можно настроить для определённого URL, для всего сайта или для всех сайтов. Но сначала надо создать файл со списком пользователей и паролей. Для этого используется утилита htpasswd. Синтаксис у команды такой:

$ sudo htpasswd -c /путь/к/файлу имя_пользователя

Опция -c используется для создания нового файла, для редактирования уже существующих её использовать не надо. Например:

sudo htpasswd -c /etc/nginx/auth.basic admin

Утилита два раза спросит пароль. Пароль вводится но не отображается. Это так должно быть для безопасности. После того, как файл будет создан можно переходить к настройке Nginx.

Для того чтобы защитить паролем все ваши сайты просто добавьте эти директиву в секцию http файла /etc/nginx/nginx.conf:

auth_basic «Restricted area»;
auth_basic_user_file /etc/nginx/auth.basic;

Для защиты только определённой URL добавьте эти же директивы в нужный блок location. Например для /wp-admin/admin-ajax.php:

location /wp-admin/admin-ajax.php <
auth_basic «Restricted area»;
auth_basic_user_file /etc/nginx/auth.basic;
>

Для WordPress такой location лучше размещать вложенным в location /. Тогда будут работать все правила описанные там, плюс ваше на защиту доступа. Если же наоборот надо разрешить доступ для определённого location то директива будут выглядеть так auth_basic «off». Например:

location /wp-admin/admin-ajax.php <
auth_basic «off»;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9002;
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
>

Здесь разместить этот блок location вложенным уже не получиться, поэтому следует добавить в него обработку php иначе веб-сервер просто предложит пользователям скачать php скрипт, к которому они обращаются.

Выводы

Как видите, авторизация по паролю nginx настраивется не так уж сложно, надо только правильно сформулировать блок location. Если у вас остались вопросы, спрашивайте в комментариях!

Источник

Nginx Basic Auth не работает

Я пытаюсь защитить сервер по умолчанию в моем конфиге Nginx. Тем не менее, при посещении сайта диалоговое окно с именем пользователя и паролем не отображается. Nginx возвращает содержимое как обычно. Вот полная конфигурация:

Интересно, что когда я попытался использовать неверный путь к файлу в качестве значения auth_basic_user_file, configtest все равно проходит. Это не должно быть так.

Вот Nginx и системная информация:

Мы используем RPM Nginx, доступный через yum.

2 ответа

Вам нужно добавить auth_basic и auth_basic_user_file внутри вашего блока местоположения вместо блока сервера.

Вы пытались перезагрузить / остановить и запустить nginx после добавления базовой аутентификации в конфигурацию? Необходимо перезагрузить nginx чем-то вроде:

—- чтобы новые настройки работали.

Также я бы дважды проверил URL, которые находятся под вашими тестами. (Однажды я попытался протестировать Nginx Basic Auth в конфигурации прокси-сервера Nginx, получая доступ к фактическому URL-адресу ресурса, находящегося за прокси-сервером Nginx, а не к фактическому URL-адресу Nginx.)

Использование неверного пути к файлу в качестве значения auth_basic_user_file по-прежнему не приводит к сбою configtest в 2018 году. Вот моя версия Nginx:

Хотя неверный путь к файлу приводит к сбою проверки базовой аутентификации и приводит к:

—- HTTP-ответ после предоставления учетных данных.

Источник

Nginx auth_basic not working for a specific url

I would like to password protect one of the URLs I have and I am trying to do it with:

The problem is that I am asked for the username and paasword. AS soon as I put the right username and password, I am getting a 404 Error with this log:

The entire nginx conf file is here

2 Answers 2

When nginx find matching location that will process request it ignores any other location that could possibly match request.

In your case before you add auth, request to /about/payment was proceeded by location / which finally passed request to PHP. But as soon as you add location /about/payment request to that URL will be processed by this location which has no special directives so nginx will try to serve static files.

You should add directives that pass request to PHP, in this case it’s really simple:

E.g. for WordPress site, I wanna lock the URL

Not the answer you’re looking for? Browse other questions tagged authentication nginx or ask your own question.

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.10.19.40495

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник