Re: unit: механизм определения адреса клиента типа realip и передача заголовков
On Thursday 16 August 2018 16:13:39 Иван wrote: > Здравствуйте! > > Кажется, до этого я отправил личное письмо. Исправляю и отвечаю в рассылку. > > 09.08.2018 10:37, Валентин Бартенев пишет: > > > On Wednesday, 8 August 2018 22:53:41 MSK Иван wrote: > >> Здравствуйте! > >> > >> Правильно ли я понимаю, что сейчас unit не умеет передавать в > >> $_SERVER['REMOTE_ADDR'] ip клиента, а не проксирующего nginx? > >> Переделывать весь наш код, чтоб брал IP из другого заголовка будет жестко. > > Да, туда в настоящий момент передается информация из сокета. > > > > Я бы сейчас решил эту задачу маленькой прослойкой в виде небольшого php > > скрипта, который заменяет содержимое $_SERVER['REMOTE_ADDR'] из HTTP_ > > заголовка, а далее выполняет уже основной скрипт, запрошенный. Так не > > потребуется вносить каких-либо изменений в остальной код, а прослойку > > в бущуем можно будет просто убрать. > > Пока что держимся на php-fpm. У нас много мелких микросервисов, везде > внедрять эту прослойку - руководство не поймет. > Проблема понятна, пока что скорого решения нет. > >> Планируется ли это исправить? Когда примерно? Сейчас это единственный > >> для меня блокирующий недостаток для внедрения unit массово в продакшен. > > Насколько я понимаю, некое подобие realip модуля решило бы Вашу задачу? > > > Конкретно с адресом бы решило. Но это необходимо, но совсем не > достаточно. Например, совершенно точно будет нехватать возможности > задать $_server[script_(file)name]. Очень многие продукты используют > ЧПУ, соотвественно без задания script_(file)name веб-сервером не > обойтись. PATH_INFO туда же. > > Или даже не ЧПУ, у на видеостриминговый сервис. Мы отадаём плейлсты (*.m3u8) > через пыху (x-accell-redirect). Как это реализовать, не задавая > SCRIPT_FILENAME? У PHP приложений есть опция "script", которая и задает SCRIPT_FILENAME. С WordPress и его ЧПУ прекрасно работает уже сейчас. > > > >> Так же интересно, когда планируется ввести возможность передавать вы > >> пыху любые заголовки массива $_SERVER, а не только HTTP_*. Это > >> собственно является решением и предыдущего вопроса. > > Сейчас это не очень простая задача. Сама по себе возможность задавать > > массив $_SERVER не представляет сложности, но вряд ли будет полезно > > указывать там какие-то константы. А что-то более осмысленное требует > > уже реализовывать поддержку переменных или какой-то похожий механизм. > > Возможно где-то к концу года, в начале следующего мы что-то подобное > > сделаем. > > > Пока что, похоже, без этого unit в прод не зайдет. Может можно "на > скорую руку" переменные вида > $_SERVER['HTTP_UNIT_VARNAME'] передавать в $_SERVER['VARNAME'] для PHP? > Это бы решило вопрос. Кто угодно может послать какие угодно заголовки, так что это будет просто небезопасно. Предполагается, что значения в $_SERVER, которые начинаются не с префикса "HTTP_", пришли не напрямую от клиента и более менее безопасны. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit: механизм определения адреса клиента типа realip и передача заголовков
Здравствуйте! Кажется, до этого я отправил личное письмо. Исправляю и отвечаю в рассылку. 09.08.2018 10:37, Валентин Бартенев пишет: > On Wednesday, 8 August 2018 22:53:41 MSK Иван wrote: >> Здравствуйте! >> >> Правильно ли я понимаю, что сейчас unit не умеет передавать в >> $_SERVER['REMOTE_ADDR'] ip клиента, а не проксирующего nginx? >> Переделывать весь наш код, чтоб брал IP из другого заголовка будет жестко. > Да, туда в настоящий момент передается информация из сокета. > > Я бы сейчас решил эту задачу маленькой прослойкой в виде небольшого php > скрипта, который заменяет содержимое $_SERVER['REMOTE_ADDR'] из HTTP_ > заголовка, а далее выполняет уже основной скрипт, запрошенный. Так не > потребуется вносить каких-либо изменений в остальной код, а прослойку > в бущуем можно будет просто убрать. Пока что держимся на php-fpm. У нас много мелких микросервисов, везде внедрять эту прослойку - руководство не поймет. >> Планируется ли это исправить? Когда примерно? Сейчас это единственный >> для меня блокирующий недостаток для внедрения unit массово в продакшен. > Насколько я понимаю, некое подобие realip модуля решило бы Вашу задачу? > Конкретно с адресом бы решило. Но это необходимо, но совсем не достаточно. Например, совершенно точно будет нехватать возможности задать $_server[script_(file)name]. Очень многие продукты используют ЧПУ, соотвественно без задания script_(file)name веб-сервером не обойтись. PATH_INFO туда же. Или даже не ЧПУ, у на видеостриминговый сервис. Мы отадаём плейлсты (*.m3u8) через пыху (x-accell-redirect). Как это реализовать, не задавая SCRIPT_FILENAME? >> Так же интересно, когда планируется ввести возможность передавать вы >> пыху любые заголовки массива $_SERVER, а не только HTTP_*. Это >> собственно является решением и предыдущего вопроса. > Сейчас это не очень простая задача. Сама по себе возможность задавать > массив $_SERVER не представляет сложности, но вряд ли будет полезно > указывать там какие-то константы. А что-то более осмысленное требует > уже реализовывать поддержку переменных или какой-то похожий механизм. > Возможно где-то к концу года, в начале следующего мы что-то подобное > сделаем. > Пока что, похоже, без этого unit в прод не зайдет. Может можно "на скорую руку" переменные вида $_SERVER['HTTP_UNIT_VARNAME'] передавать в $_SERVER['VARNAME'] для PHP? Это бы решило вопрос. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: limit req zone для одного server
И тут же сам кажется понял: limit_req_zone $binary_remote_addr$server_name zone= составной ключик нам поможет. Сорри за беспокойство. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280893,280894#msg-280894 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
limit req zone для одного server
Может я просто логику как-то не понимаю? На машине много сайтов. limit_req_zone прописываем только в http - в итоге когда ввожу ограничения - под них попадают те. кто выбирает их по ВСЕМ сайтам, а мне бы нужно только вот для конкретного. Надеюсь понятно описал... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280893,280893#msg-280893 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
