Кратко о себе: Web-разработчик. Пишу на PHP, Python, JavaScript. Знаю Ruby и Go, со студенческих времён более-менее помню C и asm. Сейчас специализируюсь на ускорении загрузки сайтов и разработке ботов для Telegram. Linuxоид (использую Debian+LXDE). Сторонник IndieWeb.
Иногда при работе с изображением с помощью PHP GD может потребоваться сохранить его в строку, а не файл. Например, такое может потребоваться для вывода картинки прямо в коде страницы в формате base64-encoded. Первое что приходит в голову — это использовать ob_start для создания дополнительного буфера вывода, вывести изображение в него, и дальше получить изображение через ob_get_clean(). Но, как выяснилось, на практике это не работает должным образом — возвращается пустая строка. Возможно, проблема в нулевых байтах или в том, что в строке есть последовательности, которые с точки зрения utf-8 являются некорректными. Но, как выяснилось, в PHP есть другое решение: открытие файла в памяти (в качестве имени файла нужно указать "php://memory") и работа с ним как с потоком. В этом случае можно добавить стандартный потоковый фильтр, кодирующий данные в base64 на лету. Это даёт возможность избежать проблем с бинарной строкой, описанных выше. Получаем такой код:
function jpeg_to_string($img, $jpeg_quality=80) {
$stream = fopen("php://memory", "w+"); // открываем поток в памяти
stream_filter_append($stream, 'convert.base64-encode', STREAM_FILTER_WRITE); //добавляем фильтр
imagejpeg($img, $stream, $jpeg_quality); // сам вывод картинки
rewind($stream); // возвращаемся к началу потока
$data = stream_get_contents($stream); // читаем содержимое потока в строку
fclose($stream);
return $data;
}
Есть в Яндекс.Вебмастере такая функция как индексация на основе обхода по счётчикам Метрики. На первый взгляд, достаточно безобидная, и Вебмастер активно уговаривает её включить. Но, на самом деле для качественно сделанного сайта она скорее вредна, чем полезна. Во-первых, из-за неё может проиндексироваться то, что для индексации вовсе не предназначено, если забыть закрыть это в robots.txt. Например, на этом сайте таким объектом могли бы стать прикреплённые в закрытых разделах форума файлы, так как доступ к ним осуществляется по URL с секретной частью. Во-вторых, сегодня обнаружил, что несколько дней назад в Яндекс добавилось большое количество новых страниц, которые затем из поиска были выброшены как дубли. Стал разбираться, в чём дело, и обнаружилось, что добавилось большое количество страниц со странными параметрами в URL вроде ?aazw46f13t=aazw46f13t. Судя по всему, кто-то прогнал сайт через сканер безопасности, а Метрика отследила все такие заходы и отправила такие страницы на индексацию, что с точки зрения SEO никакой пользы не несёт. Конечно, от этого можно защититься через указание правильного адреса страницы через canonical-адрес (тег <link rel="canonical" href="URL">). При этом если сайт сделан качественно, то есть все ссылки доступны поисковому роботу либо на страницах самого сайта, либо через sitemap.xml, индексация по Метрике никакой пользы не даёт. Поэтому, видимо, у себя на сайтах буду держать её выключенной.
Как известно, любой текст, который вводится пользователем и затем отображается на сайте, нужно обезопасить от XSS-атак — вставок JavaScript, которые могут украсть идентификатор сессии или совершить какие-либо нежелательные действия от имени пользователя. Если текст не предполагает сложного форматирования, то сделать это достаточно легко: пропустить его через функцию htmlspecialchars, которая экранирует все небезопасные символы и превратит HTML в обычный текст. Но как быть, если пользователю нужно разрешить использовать форматирование текста, например, вставку картинок, ссылок, текста с курсивом и жирным начертанием, видео?
Первое, что приходит в голову — это воспользоваться функцией strip_tags со списком разрешённых тегов. Увы, эта функция имеет существенный недостаток: если тег разрешён, то она позволяет использовать в нём любые атрибуты, в том числе и атрибуты обаботчиков событий (onclick, onmouseover и так далее), на которые легко можно повесить вредоносный код.
Другой вариант — это использование специальных языков разметки, например, BBCode или Markdown, которые затем преобразовывать в HTML. Главный недостаток такого подхода — в том, что это существенно сужает выбор WYSIWYG-редакторов, так как далеко не в каждом из них есть поддержка этих языков. Поэтому приходится прибегать к другому решению — использованию расширения DOM и удалению все тех тегов и атрибутов, которых нет в белом списке. Для начала решим, как будем задавать этот белый список. На мой взгляд, самый эффективный вариант — это хеш-массив, где ключи — это теги, а значения — массивы разрешённых для тега атрибутов (в примерах кода дальше будем считать, что он лежит в $tags, а HTML-код для очистки — в HTML) Для начала просто удалим все те теги, которых нет в списке разрешённых, с помощью функции strip_tags:
$html = strip_tags($html,'<'.join('><',array_keys($tags)).'>');
Теперь загрузим HTML-код в объект DOMDocument и создадим объект XPath для поиска атрибутов тегов и выполним этот поиск:
$html = mb_encode_numericentity($html, [0x80, 0x10FFFF, 0, ~0], 'UTF-8'); // без этого не будет корректно работать с UTF-8
if (!class_exists('DOMDocument')) throw new Exception('DOM extension not loaded!');
$dom = new DOMDocument();
$dom->formatOutput = false;
$dom->loadHTML($html,LIBXML_NONET|LIBXML_HTML_NOIMPLIED|LIBXML_HTML_NODEFDTD);
$xpath = new DOMXPath($dom);
$nodes = $xpath->query('//@*');
В переменной $nodes лежит список таких узлов-атрибутов. Пройдёмся по ним и проверим, есть ли тег (на него указывает $node->parentNode->nodeName) в списке разрешённых тегов и есть ли сам атрибут ( $node->nodeName) в списке разрешённых атрибутов для этго тега. Если его там не будет, обратимся к родительскому элементу через $node->parentNode и вызовем метод removeAttribute для его удаления.
foreach ($nodes as $node) {
$tagname = $node->parentNode->nodeName;
if (!empty($tags[$tagname])) {
$attrs = $tags[$tagname];
$attrname = $node->nodeName;
if (!in_array($attr_name,$attrs)) $node->parentNode->removeAttribute($attrname);
}
}
Теперь осталась ещё одна задача: проверить атрибуты href и src на наличие адресов вида javascript:alert('Небезопасно'). Для этого найдём с помощью XPath все атрибуты href и src, и проверим, какой протокол для ссылок используется. Если там есть слово script (так как кроме javascript, можно использовать ещё и vbscript), будем считать такую ссылку небезопасной и заменим её на безопасное значение "#":
$links = $xpath->query('//@href|//@src');
foreach ($links as $link) {
$scheme = parse_url($link->textContent,PHP_URL_SCHEME);
if (strpos(strtolower($scheme),'script')!==false) {
$link->nodeValue='#'; // removing dangerous link address
}
}
Теперь осталось только сохранить обработанный HTML-код из DOM-дерева обратно в строку:
$html = $dom->saveHTML();
Посмотреть полный код, оформленный в виде класса HTMLCleaner со статическим методом clean, можно в приложенном файле. В этом же классе определён набор констант с наиболее часто требующимися тегами и их атрибутами: TAGS_MINIMUM — только a и img, TAGS_MEDIA — для мультимедиа-тегов audio и video, TAGS_INLINE — для самых частых строчных тегов оформления, TAGS_FORMAT — для типичных блочных тегов. При необходимости их можно объединять через операцию +.
Те, кто занимается разработкой на PHP уже давно и не использует frameworks, наверное, не раз сталкивались с необходимостью правильно выводить код HTTP-ответа с правильной версией протокола и текстовым описанием (например, Ok для 200, Not Found для 404 и т.д.). Раньше для этих целей приходилось писать множество проверок условий вида: if ($status==200) header($_SERVER['HTTP_PROTOCOL'].' 200 Ok');
elseif ($status==404) header($_SERVER['HTTP_PROTOCOL'].' 404 Not Found');
// elseif обработка других статусов. Задача эта совершенно рутинная, и возникает вопрос, неужели нельзя это сделать средствами самого языка PHP. Как выяснилось, ещё в версии 5.4 такая возможность появилась — это функция http_response_code, которой достаточно передать числовой код статуса ответа. Например, если вызвать http_response_code(404), то сервер автоматически сгенерирует заголовок HTTP/1.1 404 Not Found (если запрос был по протоколу HTTP 1.1). Также можно вызвать функцию без параметров, чтобы получить код, который был установлен до этого (по умолчанию он равен 200). Так что теперь выдача заголовка сводится к всего одной строчке кода! Кроме того, в той же версии появилась ещё одна полезная функция: header_register_callback. Эта функция позволяет устанавливать обработчик, который будет вызван перед отправкой HTTP-заголовков клиенту. В нём можно использовать функции headers_list для получения списка подготовленных заголовков и header_remove для удаления тех, которые требуется исключить из отправки.
При установке Windows 10 на ноутбуки с процессорами Intel последних поколений NVMe-накопителем часто возникает ситуация, когда установщик Windows не показывает ни одного раздела, куда можно произвести установку. Объясняется это тем, что тем, что в чипсетах для процессоров 11 и более поздних поколений для работы с NVMe используется технология VMD. Для её работы BIOS (точнее, UEFI) подменяет реальные контроллеры NVMe на контроллер RST VMD. Но драйвера для него в дистрибутиве Windows 10 отсутствуют, поэтому установщик и не видит накопителя. Решить эту ситуацию можно двумя способами. Первый — зайти в BIOS и отключить использование технологии VMD (в ноутбуках от неё всё равно пользы немного). Второй — это на другом компьютере скачать драйвер RST VMD либо с сайта Intel (но он сейчас скачивание недоступно без VPN), либо с сайта какого-либо производителя ноутбуков, например, Lenovo (драйвер от производителя не зависит и должен подойти к любым ноутбукам). Далее нужно запустить скачаный EXE-файл, выбрать Extract вместо Install и распаковать драйвера на флешку (можно на флешку с дистрибутивом самого Windows, можно на отдельную). Далее начать установку Windows 10, на этапе выбора раздела нажать кнопку "Загрузить" и там указать путь к драйверу на флешке. После этого установщик должен написать, что найдено устройство Intel RST VMD, загрузить драйвер и найти раздел (возможно, потребуется нажать кнопку "Обновить"). Дальше установка должна пройти без проблем.
Часто при разработке ботов для Telegram требуется учитывать информацию о часовом поясе пользователя. К сожалению, получить её через Bot API невозможно, поэтому предусматривать в боте команду, с помощью которой пользователь сможет указать, какой часовой пояс он использует. И тут возникает вопрос, как лучше это сделать, чтобы пользователю было удобно. Если бот ориентирован только на российских пользователей, вопрос решается просто: выводим список всех часовых поясов России, пользователь выбирает нужный, и бот сохраняет выбор в базу данных. Но как быть, если пользователи могут быть из других стран? Выводить огромный список из более чем сотни часовых поясов — крайне неудобно. Требовать от пользователя вручную написать название его часового пояса в формате Europe/Moscow или хотя бы MSK — тоже не самое лучшее решение. Можно предложить указать смещение в формате ±ЧЧ:ММ, но тогда нельзя будет учесть переход на летнее время.
В поисках более удобного решения я наткнулся на модули tzwhere и geopy. Первый позволяет определить часовой пояс для того или иного местоположения, заданного с помощью координат. Второй — получить эти самые координаты по названию города, причём позволяет это делать через Google Maps API, API Яндекс.Карт и ещё почти десяток сервисов. Я решил использовать Nominatim (это сервис Open Street Maps), так как он не требует получения tokenа, в отличие от Яндекс и Google, и при этом понимает названия городов и на английском языке, и на русском. В итоге код определения часового пояса выглядит примерно так:
import geopy
from tzwhere import tzwhere
import datetime
import pytz
def get_timezone(bot,chat_id,city):
geo = geopy.geocoders.Nominatim(user_agent="SuperMon_Bot")
location = geo.geocode(city) # преобразуе
if location is None:
bot.send_message(chat_id,"Не удалось найти такой город. Попробуйте написать его название латиницей или указать более крупный город поблизости.")
else:
tzw = tzwhere.tzwhere()
timezone_str = tzw.tzNameAt(location.latitude,location.longitude) # получаем название часового пояса
tz = pytz.timezone(timezone_str)
tz_info = datetime.datetime.now(tz=tz).strftime("%z") # получаем смещение часового пояса
tz_info = tz_info[0:3]+":"+tz_info[3:] # приводим к формату ±ЧЧ:ММ
bot.send_message(chat_id,"Часовой пояс установлен в %s (%s от GMT)." % (timezone_str,tz_info))
# здесь должно быть сохранение выбранной строки в БД
return timezone_str
Приведение даты к нужному часовому поясу перед выводом пользователю делается либо с помощью метода tz.localize(dt) (для так называемых naive date, то есть не содержащих информацию о часовом поясе), либо с помощью метода dt.astimezone(tz), где dt — объект класса datetime, а tz — timezone.
Часто при поисковой оптимизации сайта возникает задача избавиться от URL, кончающихся на ?, например, http://4xpro/profblog/?. С точки зрения поисковых систем такие адреса воспринимаются как дубли. На первый взгляд, это кажется простой задачей: нужно прописать в .htaccess правило для mod_rewrite. Но при попытке это сделать вас ждёт неприятный сюрприз: этот знак вопроса не входит ни в ту часть URL, которая проверяется по RewriteRule, ни в переменную %{QUERY_STRING}, которую можно проверить с помощью RewriteCond. К счастью, решение всё же есть: использовать %{THE_REQUEST}, куда Apache помещает полную строку HTTP-запроса. Тогда получаем вот такое условие:
RewriteCond %{THE_REQUEST} \?
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L,QSD] Здесь первая строка проверяет на то, что знак вопроса вообще присутствует в запросе, вторая — на то, что QUERY_STRING пуста (то есть после знака вопроса ничего нет), и третья выполняет редирект на URL без этого знака (за это отвечает флаг QSD).
Ещё одним источником дублей является index.php. Если сделать редирект, прописав его напрямую в RewriteRule (что-то вроде RewriteRule ^/index.php$ https://%{HTTP_HOST}/ [R=301]), можем получить зацикливание. Поэтому нужно проверить, что он есть в запросе явно. Делается это с помощью %{REQUEST_URI}:
RewriteCond %{REQUEST_URI} ^/index.php$
RewriteRule ^(.*)$ https://%{HTTP_HOST}/ [R=301,L,QSA]
Иногда бывает нужно вынести адрес ссылки в скобки за её текстом, то есть преобразовать её из вида
<a href="http://example.com">Текст</a>
в формат
Текст (http://example.com)
Такое, например, полезно при выдаче данных в RSS, который впоследствии импортируется в Twitter. Делается это достаточно легко с помощью такого регулярного выражения: $text = preg_replace('|<a\W[^>]*?href=[\'"]([^>]+?)[\'"][^>]*?>(.*?)</a>|u','$2 ($1)',$text);
При разработке мультиязычного бота для Telegram возникает вопрос, на каком языке отвечать пользователю в начале диалога. Оказывается, узнать это достаточно просто: в сообщениях (объект Message) есть поле from. Оно представляет собой объект User, где имеется поле language_code, в котором и лежит код языка, выставленный у пользователя в настройках. Итоговый код на PHP будет выглядеть примерно так: $updates = $bot->getUpdates();
foreach ($updates as $item) {
$language = $item['message']['from']['language_code'];
if ($language==='ru') $response = 'Привет!';
else $response = 'Hello!';
$bot->sendMessage($response,$item['message']['chat']['id']);
}
Я уже писал о том, как отслеживать медленные запросы с помощью MySQL. Но не всегда причина бывает в базе данных. Поэтому имеет смысл применять и другой способ — использовать логи Web-серверов. В современных версиях Apache и NGinx есть возможность выводить в лог время выполнения запроса с точностью до миллисекунд. В NGinx это делается так: сначала объявляем формат лога с помощью директивы log_format и придумываем ему имя, например, logtimed. Возьмём за основу формат по умолчанию, и добавим к нему время выполнения и длину запроса. А потом объявим использование этого формата в директиве access_log: log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
' $request_time $request_length';
access_log /var/log/nginx/access.log logtimed Директива может использоваться на любом уровне (http, server, location), но в документации сказано, что следует использовать тот же, на котором прописана директива root.
В Apache требуется включить mod_log_config. Далее всё делается аналогично, только директивы называются LogFormat и CustomLog, а вывод времени запроса можно задать двумя способами — либо как %D (в микросекундах), либо как %msT (с версии 2.4.13) — в миллисекундах, либо как %T — в сеундах: LogFormat "%h %l %u %t \"%r\" %>s %b %D" logtimed
CustomLog /var/log/apache2/access.log logtimed Эти директивы можно использовать либо в глобальной конфигурации, либо на уровне VirtualHost. Надеюсь, эта информация поможет выявить медленные запросы и сделать ваши сайты и сервисы быстрее.
Здесь можно задать мне вопрос или спросить совета по любой теме, затронутой в блогах или на форуме.
После того, как я отвечу, вопрос и ответ появятся в соответствующем разделе.
Но не забываем, что я — сторонник slow life, поэтому каких-либо сроков ответов не обещаю.
Самые интересные вопросы станут основой для новых тем на форуме или записей в блоге.
Сразу предупреждаю: глупости, провокации, троллинг и тому подобное летит прямо в /dev/null.