Назад | Перейти на главную страницу

Как я могу добавить базовую аутентификацию к прокси-серверу apache при использовании заголовков CORS?

Задний план

Я использую графану для отображения графиков наших серверных метрик. Grafana - это JS-приложение, которое в нашем случае получает данные из графита и сохраняет поисковые запросы в elasticsearch. У всех трех сервисов есть свой виртуальный хост, хотя пока они находятся на одной машине. Из-за JS-правил я добавил CORS-заголовки в файл graphite- и elasticsearch-vhost. Графит-vhost - это запросы маршрутизации к WSGI, потому что графит - это приложение python / django. Elasticsearch-vhost - это обратный прокси-сервер для пересылки данных с порта. 443 к localhost:9200. Это помогает не открывать службу elasticsearch напрямую миру, а также дает мне место для добавления CORS-заголовка. Пока что это работает: графана может разговаривать с обеими службами.

Возникают проблемы

я добавил Basic Auth графанам и графит-хозяевам. Они работают нормально и, как и ожидалось. grafana может извлекать и отображать данные.

При добавлении Basic Auth к elasticsearch-vhost, я сталкиваюсь с проблемами. Пока я могу добавить Auth-настройки в <Location / >-block, похоже, отключает CORS-заголовки. С активированной аутентификацией я могу использовать elasticsearch с браузером или curl.

Однако grafana не может искать настроенные панели мониторинга в elasticsearch.

Поиск кажется более сложным, чем поиск GET, потому что графана начинается с OPTIONS-запрос. Это не срабатывает с ошибкой 401. Как ни странно, grafana может извлекать и извлекает известные информационные панели (что является простым GET).

Я не говорю об ограничении HTTP-методов в заголовках.

Итак, подведем итог:

How can I add basic auth to an apache proxy while using CORS headers?

Если вы хотите увидеть конфиги apache, скажите, пожалуйста, какие части, я не хочу публиковать три vhosts значительной длины «на всякий случай».

Я решил это, всегда позволяя OPTIONS-Запросы. Эти запросы служат только как «пинг» для проверки наличия сервера.

<Proxy *>
  Order deny,allow
  Allow from all

  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /path/to/passwords

  # This allows OPTIONS-requests without authorization
  <LimitExcept OPTIONS>
    Require valid-user
  </LimitExcept>

</Proxy>

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

В настоящее время это не ухудшает ситуацию с точки зрения безопасности:

  • OPTIONS в настоящее время нет тела, чтобы раскрыть дополнительную информацию
  • OPTIONS идемпотентен в том смысле, что он всегда ничего не делает
  • Само существование сервера также можно проверить с помощью более тяжелого GET /.
  • Все остальные HTTP-методы, кроме OPTIONS защищены паролем