Состоялся выпуск сервера приложений NGINX Unit 1.26.0, в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby, Go, JavaScript/Node.js и Java). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Код написан на языке Си и распространяется под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе первого выпуска...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56209
> /www/$host$uriА как там с санитизацией?
Nginx, помнится, этим очень славен https://blog.detectify.com/2020/11/10/common-nginx-misconfig.../
Это что то типа mod proxy в apache?
> "share": "/www/data/$uri"Мда... (Условно) Добро пожаловать в мир прочтенного "/www/data/../../etc/passwd" если будет жить как говорится установленным в localhost и запущенным от имеющего право на чтение данного файла в том числе через мандатный контроль доступа.
Добро пожаловать в документацию, чтобы осознать, что $uri содержит нормализованное значение URI, ровно такое же, какое используется всеми веб-серверами, включая nginx, для открытия файлов из document root и предотвращения выхода из него.
Остается только надеяться, что разработчики не накосячили с этим, как в Nginx, где вроде бы очевидный конфиг
location /aaa { proxy_pass http://bbb/ccc/; } позволяет, передав URL /aaa../ddd, обратиться к http://bbb/ddd
Если почтитать доку nginx, то станет понятно, что в данном конфиге часть URL запроса "/aaa" (без слеша), будет заменена на "/ccc/" (со слешом) - такая форма рерайта. Собственно, что пользователь в конфиге написал - ровно то и получил. При такой замене из "/aaa../ddd" получается "/ccc/../ddd" - что с этим будет происходить дальше зависит исключительно от бекенда.Вина nginx тут лишь в том, что пользователи не читают документацию и невнимательны. Выстрелить себе в ногу с рерайтами в любой форме - можно миллионом разных способов с любым софтом. По этой причине конфигурацией веб-севера наверное стоит доверять не домохозяйке, а кому-то компетентнее.
> При такой замене из "/aaa../ddd" получается "/ccc/../ddd" - что с этим будет происходить дальше зависит исключительно от бекенда.
> Вина nginx тут лишь в том, что пользователи не читают документацию и невнимательны.Вы, кстати, не исключение :)
Nginx нормализует URL перед передачей в бэкенд, так что туда отправится уже /ddd.> Выстрелить себе в ногу с рерайтами в любой форме - можно миллионом разных способов с любым софтом. По этой причине конфигурацией веб-севера наверное стоит доверять не домохозяйке, а кому-то компетентнее.
По этой причине лучше использовать альтернативы, у которых механизм конфигурации не является минным полем.
> Nginx нормализует URL перед передачей в бэкенд, так что туда отправится уже /ddd.Он нормализует его не перед отправкой на бекенд, а перед реврайтом, перед заменой части из location. А результат замены уже отправится на бекенд, т.е. на бекенд уйдет запрос к "/ccc/../ddd". Попробуйте сами, если не верите (только убедитесь, что сам бекенд не нормализует пришедший к нему URL).
events {}http {
server {
listen 8000;location /aaa {
proxy_pass http://127.0.0.1:8001/bbb/;
}
}server {
listen 8001;location / {
return 200 "$request_uri";
}
}
}
$ curl 127.0.0.1:8000/aaa../
/bbb/../
> По этой причине лучше использовать альтернативы, у которых механизм конфигурации не является минным полем.Ну так в каком альтернативном сервере вы бы ни написали команду: "в URL вместо букв /aaa подставь буквы /bbb/" - результат такой замены будет одинаковый. А ровно такая команда в конфиграции nginx и написана.
Можно ещё с тем же успехом команду sed ругать:
$ echo '/aaa../ddd' | sed 's+/aaa+/ccc/+'
/ccc/../ddd
Зачем такие страдания? Есть же identd.
Каких ещё приложений? Свалите со своими калькуляторами!
Это что то типа mod proxy в apache?
Блин, да когда уже на конец-то сделают возможность переопределения переменных окружения SERVER_NAME, SERVER_PORT и HTTPS?! Без этого приходится при каждом апдейте исходники править. Ибо ни laravel ни wordpress не работают на unit-е если трафик проксируется nginx-ом с https в http.Разработчики какую-то хрень непонятную пилят при этом самое базовое никак не могут реализовать... Печаль...
Вот тикет на эту тему: https://github.com/nginx/unit/issues/231
поделитесь опытом, что стало значимым фактором чтобы выбрать Nginx Unit?мне позиционирование продукта понятно не до конца, юзкейсов для себя не вижу. Предполагаю что
> The entire configuration is managed dynamically over HTTP via a friendly RESTful JSON APIкому-то обмазанному кубернейтисом нужно и может в даже мне, но (пока?) этот момент без разницы
>поделитесь опытом, что стало значимым фактором чтобы выбрать Nginx Unit?1. его скорость работы: под высокой нагрузкой с php-fpm не сравнить, в некоторых случаях разница в скорости генерации страницы в 2-5 раз быстрее. На хайлод проекте (сайт одной из популярных СМИ) это важный фактор.
2. поддержка множества языков: раньше нужно было настраивать апликейшин сервер для каждого языка свой. Частично проблема решалась при помощи uWSGI, но там тоже есть свои заморочки и проблемы. Unit стал отличной альтернативой uWSGI, к тому же чуток быстрее.
3. все таки конфигурация через апи куда удобнее если менеджить большой кластер. Раньше приходилось костылять скрипты для редактирования конфигов uWSGI и ходить по ssh на все серваки меняя их sed-ом.
4. роуты приложения: хоть и у uWSGI есть и подобный функционал, но работает он медленее + не очень удобно конфигурять на серваках централизовано.Это первое что пришло в голову. Если подумать, можно вспомнить еще пару пунктов.
> 1. его скорость работы: под высокой нагрузкой с php-fpm не сравнить, в некоторых случаях разница в скорости генерации страницы в 2-5 раз быстрее.Самый странный для меня пункт, но окей, тут можно самому протестировать и понять.
> 3. все таки конфигурация через апи куда удобнее если менеджить большой кластер. Раньше приходилось костылять скрипты для редактирования конфигов uWSGI и ходить по ssh на все серваки меняя их sed-ом.
Самый спорный для меня пункт, но возможно кому-то так действительно проще
Про остальное понятно (для меня актуально, так как не проблема менеджить nginx locations на разные бэкенды), спасибо.
"для НЕ меня актуально"
> роуты приложения: хоть и у uWSGI есть и подобный функционал, но работает он медленее + не очень удобно конфигурять на серваках централизовано.Речь идет об этом https://unit.nginx.org/configuration/#routes ?
>Речь идет об этом https://unit.nginx.org/configuration/#routes ?Да, они самые.
Там хоть один российский разработчик еще остался?
А какое отношение это имеет к "продукту"?
Главный там русский, но, опять же, что это может значить?