Так как Discourse не использует Apache, как защитить паролем, например, тестовую среду (Digital Ocean droplet с Docker-контейнером Discourse), как это делается с помощью .htaccess (Apache)?
Apache отсутствует, но внутри контейнера Discourse запущен NGINX. Эта тема может помочь:
Отлично, спасибо @david 
Только что добавил, но теперь для доступа к каждому изображению с https://cdn-uploads.example.com и https://cdn-origin.example.com требуется ввод пароля авторизации. Можно ли защитить только https://discourse.example.com?
В противном случае теперь появляется следующее:
Я не совсем уверен, как именно этого добиться, но, возможно, кто-то другой подключится, если у него будут идеи. Это должно быть возможно с некоторыми правками в конфигурации nginx.
В качестве обходного решения, и поскольку это тестовый сервер, не могли бы вы просто отключить CDN? Если вы используете тот же домен для активов, они автоматически будут получать заголовок аутентификации, так что вам не придется снова вводить пароль.
Да, конечно, если это рекомендуемый подход для среды staging, когда вы используете S3-бакеты для резервных копий и загрузок, а также CloudFront в качестве CDN для загрузок и источника для продакшена.
Неужели для среды staging действительно нужно всё это?
Это изменение в nginx, безусловно, не должно влиять на загрузки в S3 или CDN S3. NGINX там вообще не задействован. Я предположил, что вы используете локальные загрузки с CDN?
Идеальный вариант — настроить тестовый сайт идентично продакшн-сайту.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east-1
DISCOURSE_S3_ACCESS_KEY_ID: XXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_SECRET_ACCESS_KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_CDN_URL: https://cdn-uploads.example.com
DISCOURSE_S3_BUCKET: example-uploads
DISCOURSE_S3_BACKUP_BUCKET: example-backup
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_CDN_URL: https://cdn-origin.example.com
Основной домен для тестового окружения в настоящее время — https://staging.example.com
Тем не менее, при доступе к https://staging.example.com с предложенным кодом для каждого запроса от cdn-origin запрашивается аутентификация.
Обновление для тех, кто столкнулся с той же проблемой:
Нам пришлось добавить заголовки Authorization в белый список в CloudFront для cdn-origin.
Похоже, для cdn-uploads меня не запрашивали аутентификацию.
Теперь работает.
Я включил требование авторизации на тестовом сайте. Это можно сделать с помощью переменной окружения в файле app.yml, чтобы настройка сохранилась.
Недостаточно, если Google или кто-либо другой находит сайт. В любом случае, теперь работает.
Они увидят сайт, но не смогут просматривать контент. Правильно?
В нашем случае мы должны иметь возможность видеть, как сайт реагирует на анонимных пользователей. Так что всё в порядке, теперь работает с basic_auth.
Что ж, ты заставил меня переосмыслить, как я это делаю!
Привет, @Terrapop
Вот идея для вас, и именно так мы это делаем.
Если вы запускаете свою тестовую среду за Apache2 (или nginx) в качестве обратного прокси, вы можете настроить правила доступа в обратном прокси так же, как это делается с помощью .htaccess, к чему вы привыкли.
Есть множество преимуществ при запуске Discourse за обратным прокси, и простота контроля доступа — лишь одно из них.
Надеюсь, это поможет.
Есть ли проверенное пошаговое руководство по Nginx? Мы хостим на DigitalOcean через Droplet и Docker.
Привет, @Terrapop
На meta есть множество отличных руководств по настройке Discourse в конфигурации с «двумя контейнерами» за обратным прокси-сервером.
Вы можете попробовать поискать на meta:
two container reverse proxy
Надеюсь, это поможет.
Обратите внимание: для простого тестирования многие не настраивают «два контейнера» и делают это только в продакшене; однако, если вы хотите тестировать окружение «точно как в продакшене», то «два контейнера» — определённо отличный вариант. Тем не менее, для запуска веб-приложения за обратным прокси-сервером «два контейнера» не обязательны. Я регулярно запускаю веб-приложения на ROR и Docker за обратным прокси-сервером как в продакшене, так и в разработке.
Здравствуйте. Просто хочу узнать, как правильно настроить белый список заголовков авторизации в CloudFront? Добавил “auth_basic” в app.yml, как указано выше. Защита паролем работает при просмотре с компьютера, но при просмотре с мобильного устройства (после ввода логина и пароля) появляется вот это:
У меня в “cdn-origin” указано следующее:
Политика “whitelist-authorization-headers”:
Я довольно новичок в CloudFront и, возможно, просто упускаю что-то очень очевидное (в настройках для мобильных устройств).