On 17.06.2014 10:00, Maxim Dounin wrote:
>> Значения SERVER_NAME не может использоваться,
>> если в директиве server_name используется маска
>> или бекенд обрабатывает запросы для default_server.
> Если SERVER_NAME нельзя использовать - значит, необходимо
> передать дополнительный параметр, который и использовать.
Именно для этого и существует HTTP_HOST - передать
значение заголовка Host из валидного клиентского запроса.
> Использовать HTTP_* поля для чего-то, что позволяет
> "получить доступ" - это неправильно.
Если nginx не будет отправлять на backend невалидные клиентские запросы
- проблем с заголовком HTTP_HOST не будет никаких, - он будет валидным.
> Проблема в том, что приложение некорректно предполагает, что
> HTTP_HOST=private.example.com чем-то отличается от других. Как
> показывает пример запроса выше - это не так. И "не так" - не
> только в nginx'е, но и в других серверах.
А мы никаких других веб-серверов кроме nginx и не используем.
В IIS например, багов еще больше, чем в Apache, и что с того?
> Не надо себя обманывать и пытаться закрыть nginx'ом небезопасную
> логику приложения - это не работает и рано или поздно выстрелит.
Приложение было написано в соответствии со стандартами HTTP/1.1
и ожидало, что nginx не пропустит на backend невалидный запрос.
> Правильное решение - передавать информацию о произошедшей
> авторизации явно и отдельно (или пользоваться параметром
> SERVER_NAME, который уже передаётся и предназначен специально для
> идентификации сервера).
server {
server_name www.example.com example.com;
// ...
}
на backend в переменной SERVER_NAME уйдет всегда www.example.com
вне зависимости от того, к какому именно вирт. хосту был запрос.
переменную HTTP_HOST использовать нельзя.
неужели надо всем делать workaround
fastcgi_param X_REAL_HTTP_HOST $host;
и потом использовать переменную X_REAL_HTTP_HOST вместо HTTP_HOST ?
> Возможно, когда-нибудь мы и придём к тому,
> что в таких ситуациях будет возвращаться 400.
Что мешает сделать это прямо сейчас?
> Но это ни коим образом не избавляет
> от необходимости исправить приложение.
Сейчас - приходится имена виртуальных хостов прописывать
в двух местах - в настройках nginx и в настройках самого
приложения. И дополнительно валидировать HTTP_HOST, проверяя
входит ли это имя в список имен, которые были указаны в директиве
server_name, и были повторно прописаны в настройках приложения.
И если нет - то явно возвращать клиенту статус 400 Bad Request.
Есть стойкое ощущение, что это может и даже должен делать nginx.
Тогда имена хостов надо будет настраивать всего в одном конфиге.
Добавить этот workaround во все backend`ы, которые есть в мире -
это нереально, гораздо проще добавить валидацию запроса в nginx.
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
