Re: [njs] как узнать имена всех аргументов переданных в запросе?
Привет!
On 6/18/19 7:15 AM, Gena Makhomed wrote:
> Здравствуйте, All!
>
> Есть объект r.args, но он не работает согласно документации:
>
> function redirect(r) {
> // ...
> r.warn(Object.values(r.args).join(','))
> // ...
>
> - в лог пишется пустая строка. Хотя судя по документации,
> Object.values(r.args) должен был бы возвращать массив:
> https://nginx.org/en/docs/njs/reference.html#core_object
>
var args = {};
for (var k in r.args) {
args[k] = r.args[k];
}
r.log(njs.dump(args));
Оно (r.args) не совсем объект обычный, проще скопировать.
wbr,
Artem
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
[njs] как узнать имена всех аргументов переданных в запросе?
Здравствуйте, All!
Есть объект r.args, но он не работает согласно документации:
function redirect(r) {
// ...
r.warn(Object.values(r.args).join(','))
// ...
- в лог пишется пустая строка. Хотя судя по документации,
Object.values(r.args) должен был бы возвращать массив:
https://nginx.org/en/docs/njs/reference.html#core_object
P.S.
Для организации редиректов на канонический урл (для защиты от DoS/DDoS
путем обхода/отравления кеша с помощью рандомных аргументов запроса)
необходимо узнать какие именно аргументы были переданы в запросе.
Каким образом это можно сделать с помощью njs ?
Только вручную в njs парсить переменную $args ?
Применяется это примерно таким образом:
js_include conf.d/example.com.js;
js_set $stopMobileRedirect stopMobileRedirect;
js_set $x_subdomain x_subdomain;
js_set $redirect redirect;
server {
# ...
location / {
if ($redirect) {
add_header Set-Cookie $stopMobileRedirect;
return 302 $redirect;
}
# ...
}
}
--
Best regards,
Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
location + rewrite и (де)кодирование URI
Здравствуйте, All!
Есть такой фрагмент документации на директиву location:
Синтаксис: location [ = | ~ | ~* | ^~ ] uri { ... }
Для сопоставления используется URI запроса в нормализованном виде,
после декодирования текста, заданного в виде “%XX”, преобразования
относительных элементов пути “.” и “..” в реальные и возможной
замены двух и более подряд идущих слэшей на один.
Есть такой фрагмент конфига:
location ~ ^/wiki/(?.*) {
return 301 https://$host/$title$is_args$args;
}
Судя по документации, этот фрагмент конфига не должен работать, потому
что в $title ведь попадает уже декодированный русский текст из location?
Но почему-то эксперимент с помощью curl показывает, что в редиректе
возвращается текст закодированный в виде “%XX”, а не обычный Unicode.
Почему все работает именно так и как тогда надо понимать документацию?
В каких случаях в nginx необходимо вручную кодировать/декодировать
фрагменты uri и/или переменные $arg_имя а когда этого делать не надо?
--
Best regards,
Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Хотлинк работает как-то не так
Hello!
On Mon, Jun 17, 2019 at 10:03:10AM -0400, grey wrote:
> Добрый день.
>
>
> Сам конфиг, блокирующий картинки хотлинка с сайтов из "черного" списка:
>
> map $http_referer $bad_referer {
> hostnames;
>
> default 0;
>
> "~site.ru" 1;
> "~test.ru" 1;
> }
>
> location ~* ^/secret-files/
> {
> internal;
>
> if ($bad_referer)
> {
> rewrite ^ /images/direct-url.gif last;
> }
>
> root /inetpub/wwwroot/qwerty.ru;
> }
>
>
> Пока запрашиваемая картинка на моем сервере существует, правило отрабатывает
> верно и пользователи видят заглушку direct-url.gif, но если изображение на
> моем сайте удалить, то они видят сообщение, которое отдает скрипт:
>
> ...
> header ("X-Accel-Redirect: /image-not-found.gif");
> ?>
>
>
> Не понимаю, почему дело доходит до скрипта, если nginx видя хотлинк сразу
> должен отдать заглушку.
У вас в "location ~* ^/secret-files/" запрос попадает только после
обработки скриптом, судя по всему. И если скрипт не делает
перенаправления в /secret-files/, то и проверки по $bad_referer не
происходит.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Хотлинк работает как-то не так
Добрый день.
Сам конфиг, блокирующий картинки хотлинка с сайтов из "черного" списка:
map $http_referer $bad_referer {
hostnames;
default 0;
"~site.ru" 1;
"~test.ru" 1;
}
location ~* ^/secret-files/
{
internal;
if ($bad_referer)
{
rewrite ^ /images/direct-url.gif last;
}
root /inetpub/wwwroot/qwerty.ru;
}
Пока запрашиваемая картинка на моем сервере существует, правило отрабатывает
верно и пользователи видят заглушку direct-url.gif, но если изображение на
моем сайте удалить, то они видят сообщение, которое отдает скрипт:
Не понимаю, почему дело доходит до скрипта, если nginx видя хотлинк сразу
должен отдать заглушку.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,284561,284561#msg-284561
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Лимит подключений в Windows 1024 worker connections are not enough
Hello!
On Fri, Jun 14, 2019 at 02:57:25AM -0400, Krelion wrote:
> Добрый день!
>
> Nginx 1.15.9 для Windows
>
> конфиг,
>
> worker_processes 1;
>
> events {
> worker_connections 8192;
> }
>
> в логах:
>
> 2019/06/07 14:17:20 [alert] 2424#2720: 1024 worker_connections are not
> enough
>
> Как поднять количество соединений больше 1024 в версии под Windows ?
> В моем случае невозможно использовать Linux версию по ряду причин.
Если вам нужно больше 1024 соединений в Windows-версии, то вы,
вероятно, используете nginx для Windows неправильно - не надо на
этом гонять production, от этого может быть больно. Впрочем,
начиная с nginx 1.15.9 при условии использования Windows Vista и
новее - это можно сделать, сказав к конфиге "use poll;" в секции
events.
При этом, правда, отвалится детектирование ошибок на этапе
установления соединения к бэкендам, так как правильную эмуляцию
poll() в MS не осилили.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
