#1240 closed defect (wontfix)
ngx_http_userid_module uid_set
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | major | Milestone: | |
Component: | nginx-module | Version: | 1.10.x |
Keywords: | userid uid_set | Cc: | |
uname -a: | Linux bulat 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux | ||
nginx -V: |
nginx version: nginx/1.10.1
built with OpenSSL 1.0.1f 6 Jan 2014 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_secure_link_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-threads --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/headers-more-nginx-module --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-auth-pam --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-cache-purge --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-development-kit --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-echo --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/ngx-fancyindex --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-http-push --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-lua --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-upload-progress --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/nginx-upstream-fair --add-module=/build/nginx-abUnII/nginx-1.10.1/debian/modules/ngx_http_substitutions_filter_module |
Description
была попытка использования модуля ngx_http_userid_module совместно с сегментацией через split_clients, которому на вход подавалась строка "${uid_got}${uid_set}"
полученый сегмент использовался в fullpage кэше, в качестве ключа
проблема в том что uid полученый при первом заходе и сохраненный в куку, изменялся при втором заходе. чтобы воспроизвести это достаточно хоть как-то использовать $uid_set и после этого мы получаем разницу между тем что в заголовках выставлено в куках, и собственно значением в этом функции. Возможно тут играет роль, что используется memcached конфигурация, которая работает через error_page, и тут возможно что-то обнуляется
предположение что
Change History (3)
comment:1 by , 8 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 8 years ago
Если кто-то сюда придет после. то проблема решилась через с помощью lua. там поведение оказалось предсказуемое
comment:3 by , 8 years ago
sensitive: | 1 → 0 |
---|
Вероятнее всего, ваша проблема не в том, что uid не тот, что сохранён в куках, а в том, что вы используете переменную $uid_set до собственно возврата ответа клиенту, и она имеет не то значение, которое реально устанавливается клиенту в куке.
Предположение верное - при внутренних перенаправлениях обнуляются контексты модулей. В результате в случае, если после использования $uid_set случится внутреннее перенаправление, значение устанавливаемой клиенту куки будет сгенерировано заново (в соответствии с новой конфигурацией) и не будет совпадать с тем, что вы получили ранее из переменной $uid_set.