Re: BasicAuth только с определенных IP
satisfy any; -- With best regards, Dmitriy Lyalyuev dmit...@lyalyuev.info > On Nov 7, 2018, at 06:16, inkognito0609 wrote: > > Необходимо чтобы из внутренней сети доступ был без авторизации, из внешней > сети для разрешенных определенных адресов запрашивался пароль > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281796,281846#msg-281846 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru smime.p7s Description: S/MIME cryptographic signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: pipe to http
X-Accel-Redirect похоже то, что вам нужно. -- With best regards, Dmitriy Lyalyuev dmit...@lyalyuev.info > On Nov 7, 2018, at 02:59, Nick Knutov wrote: > > Доброго времени суток, > > подскажите, как лучше реализовать такую задачу: > > запрос приходит к nginx, отправляется некоторому скрипту (uwsgi->perl), > который проверяет авторизацию, и если всё ок, то необходимо запустить > какой-то процесс, который отдаст много гигабайт данных в stdout и это надо > отдать хттп-клиенту. > > Причем, важно, если клиент отвалился - процесс нужно убить. > > Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше перловым > скриптом, но он ест неприемлемо много проца и имеет непонятные проблемы с > буферизацией и медленными клиентами. Нельзя ли в скрипте ограничиться чем-то > вроде внутреннего редиректа и остальную работу сделать на уровне nginx? > > -- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru smime.p7s Description: S/MIME cryptographic signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: как правильно прописать путь до статики
в /srv/www/frontend/build/ лежит html файл в котором прописан путь до
статики - /static/css/main.0a23196b.css
Но при обработке->
location /restore {
alias /srv/www/frontend/build/;
rewrite ^/restore$ /restore/;
Статику ищет с добавлением restore
localhost/restore/static/css/main.0a23196b.css
как убрать restore, так как планируется добавление новых location по данному
шаблону?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,281795,281847#msg-281847
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: BasicAuth только с определенных IP
Необходимо чтобы из внутренней сети доступ был без авторизации, из внешней сети для разрешенных определенных адресов запрашивался пароль Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281796,281846#msg-281846 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
pipe to http
Доброго времени суток, подскажите, как лучше реализовать такую задачу: запрос приходит к nginx, отправляется некоторому скрипту (uwsgi->perl), который проверяет авторизацию, и если всё ок, то необходимо запустить какой-то процесс, который отдаст много гигабайт данных в stdout и это надо отдать хттп-клиенту. Причем, важно, если клиент отвалился - процесс нужно убить. Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше перловым скриптом, но он ест неприемлемо много проца и имеет непонятные проблемы с буферизацией и медленными клиентами. Нельзя ли в скрипте ограничиться чем-то вроде внутреннего редиректа и остальную работу сделать на уровне nginx? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: BasicAuth только с определенных IP
Hello! On Tue, Nov 06, 2018 at 05:24:58AM -0500, inkognito0609 wrote: > Модуль ngx_http_access_module позволяет ограничить доступ для определённых > адресов клиентов. > ngx_http_auth_basic_module позволяет ограничить доступ к ресурсам с > проверкой имени и пароля. > > Можно ли реализовать проверку имени и пароля при условии входа с > определенных ip адресов?, если да то как? Есть директива satisfy, она позволяет произвольно комбинировать access (allow/deny) и auth_basic. Подробнее про неё рассказано в документации тут: http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy Поведение по умолчанию - "satisfy all", то есть проверяются результаты как allow/deny, так и auth_basic. То есть для того, чтобы доступ был разрешён только с определённых IP-адресов, и при этом у пришедших с этих адресов спрашивалась авторизация, достаточно написать: allow 192.168.0.0/24; deny all; auth_basic "restricted site"; auth_basic_user_file /path/to/htpasswd; При этом nginx сначала проверит IP-адрес, и если доступ с этого IP-адреса запрещён - вернёт ошибку. Если же вдруг я неверно понял вопрос и на самом деле зачем-то хочется, чтобы доступ был разрешён всем, но с определённых IP-адресов - только с авторизацией, то можно использовать "satisfy any", и разрешить доступ от всех адресов, кроме тех, у которых нужно спрашивать авторизацию: satisfy any; deny 192.168.0.0/24; allow all; auth_basic "restricted site"; auth_basic_user_file /path/to/htpasswd; -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как приоритизировать шифры для TLSv1.3?
Hello! On Mon, Nov 05, 2018 at 07:38:46AM -0500, I0Result wrote: > я смотрю openssl добавил другой параметр для сортировки шифров -ciphersuites > (https://www.openssl.org/docs/man1.1.1/man1/ciphers.html) > Если запускать команду, то шифры начинают приоритезироваться > openssl ciphers -ciphersuites > TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 > -s -v EECDH+CHACHA20:EECDH+AESGCM | column -t > > TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any > Enc=CHACHA20/POLY1305(256) Mac=AEAD > TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=anyEnc=AESGCM(256) > Mac=AEAD > TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=anyEnc=AESGCM(128) > Mac=AEAD > ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD > ECDHE-RSA-CHACHA20-POLY1305TLSv1.2 Kx=ECDH Au=RSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD > ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) > Mac=AEAD > ECDHE-RSA-AES256-GCM-SHA384TLSv1.2 Kx=ECDH Au=RSAEnc=AESGCM(256) > Mac=AEAD > ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) > Mac=AEAD > ECDHE-RSA-AES128-GCM-SHA256TLSv1.2 Kx=ECDH Au=RSAEnc=AESGCM(128) > Mac=AEAD > > Как быть с настройками nignx? Напрямую через конфигурацию nginx настроить шифры для TLSv1.3 сейчас нельзя - подробнее почитать о том, почему так, можно тут: https://trac.nginx.org/nginx/ticket/1529 In short: в OpenSSL выпилили управление шифрами для TLSv1.3 из стандартного интерфейса, и непонятно, запилят ли обратно. Делать же отдельную директиву аналогично "-ciphersuites" крайне не хочется, ибо это выглядит как идиотизм чуть менее, чем полностью. Если очень хочется - сейчас шифры для TLSv1.3 можно задать через конфиг OpenSSL'я, openssl.conf. Как-то так: openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] Ciphersuites = TLS_CHACHA20_POLY1305_SHA256 -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[nginx-ru-announce] nginx security advisory (CVE-2018-16845)
Hello! В модуле ngx_http_mp4_module была обнаружена ошибка, которая позволяет с помощью специально созданного mp4-файла вызвать бесконечный цикл в рабочем процессе, падение рабочего процесса, либо же могла приводить к отправке клиенту содержимого памяти рабочего процесса (CVE-2018-16845). Проблеме подвержен nginx, если он собран с модулем ngx_http_mp4_module (по умолчанию не собирается) и директива mp4 используется в конфигурационном файле. При этом атака возможна только в случае, если атакующий имеет возможность обеспечить обработку специально созданного mp4-файла с помощью модуля ngx_http_mp4_module. Проблеме подвержен nginx 1.1.3+, 1.0.7+. Проблема исправлена в 1.15.6, 1.14.1. Патч, исправляющий проблему, доступен тут: http://nginx.org/download/patch.2018.mp4.txt -- Maxim Dounin http://nginx.org/ ___ nginx-ru-announce mailing list nginx-ru-announce@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru-announce
[nginx-ru-announce] nginx security advisory (CVE-2018-16843, CVE-2018-16844)
Hello! В реализации HTTP/2 в nginx были обнаружены две проблемы безопасности, которые могут преводить к чрезмерному потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). Проблемам подвержен nginx, собранный с модулем ngx_http_v2_module (по умолчанию не собирается), если в конфигурационном файле используется параметр http2 директивы listen. Проблемам подвержен nginx 1.9.5 - 1.15.5. Проблемы исправлены в nginx 1.15.6, 1.14.1. Спасибо Gal Goldshtein из F5 Networks за исходное сообщение о проблеме с потреблением ресурсов процессора. -- Maxim Dounin http://nginx.org/ ___ nginx-ru-announce mailing list nginx-ru-announce@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru-announce
[nginx-ru-announce] nginx-1.14.1
Изменения в nginx 1.14.1 06.11.2018 *) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). *) Безопасность: при обработке специально созданного mp4-файла модулем ngx_http_mp4_module содержимое памяти рабочего процесса могло быть отправлено клиенту (CVE-2018-16845). *) Исправление: при работе с gRPC-бэкендами могло расходоваться большое количество памяти. -- Maxim Dounin http://nginx.org/ ___ nginx-ru-announce mailing list nginx-ru-announce@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru-announce
nginx security advisory (CVE-2018-16845)
Hello! В модуле ngx_http_mp4_module была обнаружена ошибка, которая позволяет с помощью специально созданного mp4-файла вызвать бесконечный цикл в рабочем процессе, падение рабочего процесса, либо же могла приводить к отправке клиенту содержимого памяти рабочего процесса (CVE-2018-16845). Проблеме подвержен nginx, если он собран с модулем ngx_http_mp4_module (по умолчанию не собирается) и директива mp4 используется в конфигурационном файле. При этом атака возможна только в случае, если атакующий имеет возможность обеспечить обработку специально созданного mp4-файла с помощью модуля ngx_http_mp4_module. Проблеме подвержен nginx 1.1.3+, 1.0.7+. Проблема исправлена в 1.15.6, 1.14.1. Патч, исправляющий проблему, доступен тут: http://nginx.org/download/patch.2018.mp4.txt -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[nginx-ru-announce] nginx-1.15.6
Изменения в nginx 1.15.6 06.11.2018 *) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). *) Безопасность: при обработке специально созданного mp4-файла модулем ngx_http_mp4_module содержимое памяти рабочего процесса могло быть отправлено клиенту (CVE-2018-16845). *) Добавление: директивы proxy_socket_keepalive, fastcgi_socket_keepalive, grpc_socket_keepalive, memcached_socket_keepalive, scgi_socket_keepalive и uwsgi_socket_keepalive. *) Исправление: если nginx был собран с OpenSSL 1.1.0, а использовался с OpenSSL 1.1.1, протокол TLS 1.3 всегда был разрешён. *) Исправление: при работе с gRPC-бэкендами могло расходоваться большое количество памяти. -- Maxim Dounin http://nginx.org/ ___ nginx-ru-announce mailing list nginx-ru-announce@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru-announce
nginx-1.14.1
Изменения в nginx 1.14.1 06.11.2018 *) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). *) Безопасность: при обработке специально созданного mp4-файла модулем ngx_http_mp4_module содержимое памяти рабочего процесса могло быть отправлено клиенту (CVE-2018-16845). *) Исправление: при работе с gRPC-бэкендами могло расходоваться большое количество памяти. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx security advisory (CVE-2018-16843, CVE-2018-16844)
Hello! В реализации HTTP/2 в nginx были обнаружены две проблемы безопасности, которые могут преводить к чрезмерному потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). Проблемам подвержен nginx, собранный с модулем ngx_http_v2_module (по умолчанию не собирается), если в конфигурационном файле используется параметр http2 директивы listen. Проблемам подвержен nginx 1.9.5 - 1.15.5. Проблемы исправлены в nginx 1.15.6, 1.14.1. Спасибо Gal Goldshtein из F5 Networks за исходное сообщение о проблеме с потреблением ресурсов процессора. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx-1.15.6
Изменения в nginx 1.15.6 06.11.2018 *) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). *) Безопасность: при обработке специально созданного mp4-файла модулем ngx_http_mp4_module содержимое памяти рабочего процесса могло быть отправлено клиенту (CVE-2018-16845). *) Добавление: директивы proxy_socket_keepalive, fastcgi_socket_keepalive, grpc_socket_keepalive, memcached_socket_keepalive, scgi_socket_keepalive и uwsgi_socket_keepalive. *) Исправление: если nginx был собран с OpenSSL 1.1.0, а использовался с OpenSSL 1.1.1, протокол TLS 1.3 всегда был разрешён. *) Исправление: при работе с gRPC-бэкендами могло расходоваться большое количество памяти. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Настройка протокола FastCGI для high load
On Tuesday 06 November 2018 06:25:36 kseleznyov wrote: > Добрый день! > > Проблема такая. Мы используем библиотеку libfcgi. Она популярная, хорошо про > тестированная и т.д. и т.п., но... она не поддерживает переиспользование > соединений. Может быть посоветуете другую библиотеку для c++? > > Если же использовать libfcgi, то поясню свой предыдущий вопрос. Допустим > nginx уже открыл N соединений FastCGI и по каждому из них уже обрабатывается > FastCGI-запрос. Допустим приходит ещё один HTTP-запрос и у nginx есть три > пути: либо открывать ещё одно FastCGI-соединение для обработки нового > HTTP-запроса, либо откладывать этот HTTP-запрос (пока не отработает один из > N запросов), либо вообще возвращать ошибку. Как поступает nginx? Какие > настройки на это влияют? > 1. nginx по умолчанию _всегда_ открывает новое соединение. И это должно работать с libfcgi без проблем. 2. Если вы настроили keepalive (http://nginx.org/r/keepalive/ru), то при наличии свободного соединения (в котором не обрабатывается запрос) - будет использоваться это соединение, в противном случае открываться новое. 3. Если вы установили параметр max_conns у директивы server, то при превышении данного значения nginx будет пытаться выбрать другой сервер, а при неудаче - возвращать ошибку. 4. Откладывать nginx умеет только в коммерческой версии с помощью директивы queue (http://nginx.org/r/queue/ru). -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Настройка протокола FastCGI для high load
вт, 6 нояб. 2018 г. в 16:25, kseleznyov : > Добрый день! > > Проблема такая. Мы используем библиотеку libfcgi. Она популярная, хорошо > про > тестированная и т.д. и т.п., но... она не поддерживает переиспользование > соединений. Может быть посоветуете другую библиотеку для c++? > > Если же использовать libfcgi, то поясню свой предыдущий вопрос. Допустим > nginx уже открыл N соединений FastCGI и по каждому из них уже > обрабатывается > FastCGI-запрос. Допустим приходит ещё один HTTP-запрос и у nginx есть три > пути: либо открывать ещё одно FastCGI-соединение для обработки нового > HTTP-запроса, либо откладывать этот HTTP-запрос (пока не отработает один из > N запросов), либо вообще возвращать ошибку. Как поступает nginx? Какие > настройки на это влияют? > как уже ответил Валентин - nginx будет пытаться оставить соединение в пуле, если а) вы сделали настройки (которые он показал) б) если бекенд его не закроет > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281762,281797#msg-281797 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Настройка протокола FastCGI для high load
Добрый день! Проблема такая. Мы используем библиотеку libfcgi. Она популярная, хорошо про тестированная и т.д. и т.п., но... она не поддерживает переиспользование соединений. Может быть посоветуете другую библиотеку для c++? Если же использовать libfcgi, то поясню свой предыдущий вопрос. Допустим nginx уже открыл N соединений FastCGI и по каждому из них уже обрабатывается FastCGI-запрос. Допустим приходит ещё один HTTP-запрос и у nginx есть три пути: либо открывать ещё одно FastCGI-соединение для обработки нового HTTP-запроса, либо откладывать этот HTTP-запрос (пока не отработает один из N запросов), либо вообще возвращать ошибку. Как поступает nginx? Какие настройки на это влияют? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281762,281797#msg-281797 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: как правильно прописать путь до статики
вт, 6 нояб. 2018 г. в 15:09, inkognito0609 :
> server {
> ...
> root /srv/www/app/web;
>
> index index.php index.html;
>
> port_in_redirect off;
> if (!-e $request_filename) {
> rewrite ^/(.*)/$ https://$host/$1 permanent;
> }
>
безотносительно вашего исходного вопроса (я не в курсе, что у вас
сломалось)
есть няшная штука для проверки, есть файл или нет файла - try_files
там под капотом ровно то же, что у вас, но синтаксис получается читаемый
>
> location /restore {
> alias /srv/www/frontend/build/;
> rewrite ^/restore$ /restore/;
> ...
> При открытии страницы localhost/restore не может найти статику
> static/css/main.css
> Status Code: 404 Not Found
>
> /srv/www/frontend/build/static/css/
> /srv/www/frontend/build/static/js/
> /srv/www/frontend/build/static/media/
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,281795,281795#msg-281795
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
BasicAuth только с определенных IP
Модуль ngx_http_access_module позволяет ограничить доступ для определённых адресов клиентов. ngx_http_auth_basic_module позволяет ограничить доступ к ресурсам с проверкой имени и пароля. Можно ли реализовать проверку имени и пароля при условии входа с определенных ip адресов?, если да то как? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281796,281796#msg-281796 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
как правильно прописать путь до статики
server {
...
root /srv/www/app/web;
index index.php index.html;
port_in_redirect off;
if (!-e $request_filename) {
rewrite ^/(.*)/$ https://$host/$1 permanent;
}
location /restore {
alias /srv/www/frontend/build/;
rewrite ^/restore$ /restore/;
...
При открытии страницы localhost/restore не может найти статику
static/css/main.css
Status Code: 404 Not Found
/srv/www/frontend/build/static/css/
/srv/www/frontend/build/static/js/
/srv/www/frontend/build/static/media/
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,281795,281795#msg-281795
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
