12 январь 2021 Nginx


certbot --dry-run --manual --agree-tos --preferred-challenges dns certonly --server https://acme-v02.api.letsencrypt.org/directory  -d *.sitename.ru -d sitename.ru -m webmaster@sitename.ru

в два захода добавляем TXT записи с именем _acme-challenge и выводимыми утилитой значениями

certbot --manual --agree-tos --preferred-challenges dns certonly --server https://acme-v02.api.letsencrypt.org/directory  -d *.sitename.ru -d sitename.ru -m webmaster@sitename.ru

добавляем ещё одно значение _acme-challenge

cat  /etc/letsencrypt/live/sitename.ru/fullchain.pem /etc/letsencrypt/live/sitename.ru/privkey.pem >  /etc/haproxy/certs/www.sitename.ru.pem

генерируем контейнер и перезапускаем балансировщик

haproxy -c -V -f /etc/haproxy/haproxy.cfg && service haproxy reload

 


28 сентябрь 2018 20 апрель 2021 Nginx


Не все знают зачем к имени сайта добавляют префикс www., по мимо субъективных причин, про world wide web и удобство парсинга урлов есть совершенно объективная причина использовать алиас WWW.

Всё дело в структуре протокола DNS, когда происходит преобразование доменного имени обычного домена первого уровня, то происходит запрос к корневому серверу зоны, а корневые сервера зон обновляются достаточно редко, например в зоне .RU обновление происходит 4 раза в день, а при преобразовании домена третьего уровня, про выполняется запрос к DNS серверу контролирующему домен, а он обновляется быстрее чем корневые сервера зоны.

Таким образом, если у вас отключили сервер сайта, и вы меняете IP адрес парковки домена на IP адрес резервного, то вашим клиентам придётся ждать обновления корневого DNS, а если меняется IP адрес у алиаса WWW.yourdomain то обновление произойдёт гораздо быстрее, в некоторых случаях сразу


28 май 2018 Nginx



Есть стереотип, что жители китая любят копировать готовое, а значит необходимо защищать от них контент, особенно медиа контент. Обычно это делается так:

Но в случае применения такого метода остаётся возможность получить доступ через Proxy/VPN либо воспользовать кешем любого поисковика, а они подтянут с сайта все защищаемые картинки

При  этом необходимо так же следить за актуальностью базы данных IP адресов или за состояние API сервиса

Если такие условия и ограничения не являются приелимыми, то можно воспользоваться возможностью веб-сервера Nginx фильтровать входящие запросы по HTTP-заголовкам. Суть этого метода в том, что у любого человека его родной язык включён в список языков его веб-браузера, таким образом у китайца среди всех языков, которые он использует есть китайский, а значит в его запросе на сайт будет присутвовать вот такой HTTP-заголовок

Accept-language: zh,ru;q=0.8,en-US;q=0.5,en;q=0.3

Значит нужно научить веб-сервер выделять таких клиентов и направлять их туда куда нужно, я сделал это вот так

map $http_accept_language $lang {
    default ru;
    ~by by;
    ~ru ru;
    ~zh zh;
}

location /media/ {
        # если китаец
        set $redir  0;
        if ( $lang ~* 'zh' ){
            set $redir  1;
        }
        # если запрос фотографии
        if ( $request_uri ~* \.(jpeg|jpg|png)$ ){
            set $redir  2$redir;
        }
        if ( $redir = 21 ){
            rewrite /media/(.*) /media_v/$1?lang=$lang&redir=$redir&$http_referer;
        }

        alias /webapps/centrsvet/media/;
    }

location /media_v/ {
            image_filter_jpeg_quality 10;
            image_filter resize 700 600;
            alias /webapps/centrsvet/media/;
    }

защита фотографий от китайцев

В результате, любой китаец сможет зайти на сайт но вместо качественных картинок он получит уменьшенные и обрезанные копии, не пригодные для коммерческого использования, а так же он получит такие же негодные картинки если откроет страницу сайта в кеше любого поисковика