Ограничение количества записей для заказов в bitrix

Posted in Новости on июня 11, 2019 by admin

Штатно количество отображаемых записей регулируется GET параметром SIZEN_1 , соответственно, нам требуется узнавать параметр и в случае его превышения сбрасывать до стандартного значения. Так как в стандартном решении nginx нет необходимого компаратора, то решение написал на lua ( соответственно этот модуль должен быть включен в nginx ). Вставляем решение в location ~ \.php$ :

    set $rew 0;
    rewrite_by_lua_block {
      local rf = ngx.var.request_filename
      local args = ngx.var.args
      if rf == ngx.var.document_root .. "/bitrix/admin/sale_order.php" then
        if ngx.var.arg_SIZEN_1 and tonumber(ngx.var.arg_SIZEN_1) > 50 then
          newargs, n, err = ngx.re.gsub(args, [[\bSIZEN_1=[^&]*&?]], "SIZEN_1=50&", "jo")
          if n and n > 0 then
            ngx.var.args = newargs
            local urito = ngx.var.scheme .. "://" .. 
ngx.var.server_name .. "/bitrix/admin/sale_order.php?" .. ngx.var.args
            ngx.redirect(urito)
          end
        end
        if ngx.var.arg_SHOWALL_1 and tonumber(ngx.var.arg_SHOWALL_1) > 0 then
          newargs, n, err = ngx.re.gsub(args, [[\bSHOWALL_1=[^&]*&?]], "SIZEN_1=50&", "jo")
          if n and n > 0 then
            ngx.var.args = newargs
            local urito = ngx.var.scheme .. "://" .. 
ngx.var.server_name .. "/bitrix/admin/sale_order.php?" .. ngx.var.args
            ngx.redirect(urito)
          end
        end
      end
    }

Tags: , ,

git clone https bitbucket fails at 1Gb

Posted in Новости on мая 15, 2019 by admin

Проблема :

bitbucket работает за nginx. При скачивании репозитория через https больше, чем 1Гб , гит сбрасывает соединение с ошибкой.

Решение :

Требуется либо отключить буферизацию на стороне nginx, либо отключить/увеличить лимит у proxy_max_temp_file_size , который стандартно как раз и выставлен в 1Гб.

Tags: , , , ,

Перенос/создание редиректов для nginx при помощи lua и redis

Posted in Новости on июня 19, 2018 by admin

В процессе работы появилась задача организовать порядка 1500 редиректов для сайта. Конечно, можно просто сгенерировать локейшены и подцепить их инклудом, но подобное решение во-первых является не совсем красивым, а во-вторых довольно медленным, ведь nginx придется проходить для каждого запроса все локейшены. Выбор упал на lua + redis , так как redis является inmemory СУБД ( хоть и nosql ) и довольно быстра.
Итак, мы собрали nginx с модулем lua и готовы творить.
У меня получился вот такой конфиг :

server {
listen 80;
location / {
access_by_lua '
local redis = require "resty.redis"
local red = redis:new()
red:set_timeout(1000)
local ok, err = red:connect("127.0.0.1", 6379)
local key = ngx.var.request_uri
local res, err = red:get(key)
if res ~= ngx.null then
ngx.redirect(res, 301)
end
';
rewrite ^(.*)$ /index.html break;
}
location /value1 { return 505; }
}

Долго мучался с access_by_lua , так как глубоких знаний lua у меня пока нет, а во всех источниках люди пишут content_by_lua. В итоге, прошерстив документацию, я пришел к выводу, что content_by_lua можно использовать только тогда, когда в этом же локейшене нет других рерайтов, proxy_pass и прочего от nginx . В текущем конфиге с content_by_lua я получал безусловный рерайт на /index.html не учитывая мою логику lua. А access_by_lua учитывает подобное поведение, что мне на руку. Дополнительный локейшен /value1 использую для теста конфига. Если в redis есть ключ со значением /value1 , то мы получим редирект и 505 код, если же ключа не существует, то нам просто отдастся стандартная страница openresty ( я использовал docker образ openresty/openresty:alpine для тестирования ).

Итак,

стартуем образ nginx :

docker run --net host -d -v /srv/docker/nginx/:/etc/nginx/conf.d openresty/openresty:alpine

далее стартуем наш редис :

docker run --net host -d redis

вносим в redis наши данные :

redis-cli set /v1234 /value1

Проверяем :
http://localhost/v123 — ( нет такого ключа в редисе ) — получаем индексную страницу
http://localhost/v1234 — ( есть такой ключ со значением /value1 ) — получаем 301 редирект и 505 код. Ура.

Конечно, в коде нет проверки на корректность подключения и доступность самого редиса, но это черновой вариант с рабочей логикой, который расширить не составит никакого труда.

Tags: , , , ,

moodle slasharguments nginx php-fpm

Posted in Новости on января 31, 2016 by admin

Если moodle установлен в корень сайта ( DOCROOT ) и доступен как, http://site.com/ , то для активации slash arguments нужно в nginx в конфиге сайта в блоке server прописать :

rewrite ^/(.*\.php)(/)(.*)$ /$1?file=/$3 last;

Tags: , ,

nginx и бесплатные сертификаты от let's encrypt

Posted in Новости on января 29, 2016 by admin

1. Ставим само ПО letsencrypt :

cd /usr/src
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto

В процессе установки попросят ввести ящик. Он потребуется для продления сертификата или при утере данных
2. Генерируем сертификаты для работы :

cd /usr/src
service nginx stop
./letsencrypt-auto certonly --standalone
service nginx start

В процессе генерации ключей нас попросят ввести список доменов, если нам нужно разместить более одного домена второго уровня, тогда нужно будет запустить еще раз утилиту, так как для всего списка создается один сертификат. Перед генерацией сертификата нужно останавливать вебсервер.
3. Создаем минимальный конфиг nginx для ssl :

server {
listen my.ip.ad.dre.ss:443 ssl;
server_name example.com www.example.com;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
set $root /var/www/example.com/;
ssl on;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
root $root;
}
}

сертификат fullchain.pem уже включает и сертификат домена и цепочку сертификатов.

Tags: , , , ,