Сегодня явно день патчей

Полтора месяца назад я уже писал про замечательный плагин Wassup, а также о его нелюбви к Windows. Помимо этой ошибки, я обратил внимание на нелюбовь плагина к строкам, состоящим из многобайтных символов (например, UTF-8).

Сегодняший патч исправляет:

• проблему с разделителями каталогов (традиционно);
• мелкие ошибки, связанные с невалидностью генерируемого HTML-кода;
• добавляет поддержку строк, состоящим из многобайтных символов (поддержка таких строк требует наличия активированного расширения PHP mb_string);
• добавляет rel="nofollow" к ссылкам в блоках типа 'Top 5 Referrers', 'Top 5 Search Terms'.

Скачать патч в формате unified diff.

Патч нужно применить рекурсивно к каталогу /wp-content/plugins/wassup.

Так уж случилось, что пришлось заняться разработкой расширений для Typo3. Так вот получилось, что буквально через 15 минут тесного знакомства я нарвался на фатальную ошибку, вызванную расширением ExtDevEval:

Fatal error: Cannot re-assign $this in /var/www/typo3.sjinks.org.ua/typo3conf/ext/extdeveval/class.tx_extdeveval_fetchContentTopMenu.php on line 36

Читать статью «Typo3, ExtDevEval и PHP5: избавляемся от фатальных ошибок» полностью…

FCrDNS, или Forward Confirmed Reverse DNS, это когда IP-адрес имеет прямую (имя -> IP) и обратную (IP -> имя) DNS-записи, которые, к тому же, соответствуют друг другу.

Сначала выполняется обратный DNS-запрос для получения списка PTR-записей (обычно возвращается только одна запись, но это не всегда так). Затем для каждого доменного имени, указанного в PTR-записях, выполняется обычный (прямой) DNS-запрос с целью проверки, что существует запись A или AAAA, совпадающая с исходным IP-адресом. Если это так, то проверка считается пройденной.

Проверка FCrDNS может считаться слабой формой аутентификации, устанавливающей, что есть действительная связь между владельцем доменного имени и владельцем сети, получившим данный IP-адрес. Хотя такая аутентификация и слаба, она достаточно хороша, для того, чтобы отсеивать спамеров и иже с ними, использующих компьютеры-зобми для подделки доменов.

Перевод Forward Confirmed reverse DNS.

А теперь о практической реализации. Читать статью «Forward Confirmed reverse DNS, или, Зомби не пройдут» полностью…

Как-то на досуге я занялся анализом приходящего спама и обратил внимание, что практически 98% спама в комментариях приходят с IP-адресов, замеченных в рассылке спама по электронной почте. А спамеры обычно попадают в черные списки (blacklist).

DNSBL — DNS blacklist или DNS blocklist — списки хостов, хранимые с использованием системы архитектуры DNS. Обычно используются для борьбы со спамом. Почтовый сервер обращается к DNSBL, и проверят в нём наличие IP-адреса клиента, с которого он принимает сообщение. При положительном ответе считается, что происходит попытка приёма спам-сообщения, и оно блокируется (не принимается сервером, и, как правило, отправителю отсылается уведомление об этом).

Идея состоит в том, чтобы написать расширение для WordPress, проверяющее наличие IP-адреса комментатора в чёрном списке. Читать статью «Использование DNSBL для борьбы со спамом в комментариях» полностью…

Я сейчас работаю над очень интересным проектом, который, как надеется заказчик, составит серьёзную конкуренцию Google Analytics. Но речь не об этом. Разбираясь с архитектурой системы, я обнаружил весьма интересную деталь: 8 гигабайт памяти сервера отдается под несколько таблиц типа HEAP. Так как HEAP-таблицы хранятся в исключительно в памяти, то операция вставки (INSERT) должна выполняться очень быстро, так как временные затраты, связанные с перемещением головок диска и физической записью, отсутствуют. Я решил найти подтверждение этой теории. Google is your friend, и я довольно быстро нашел статью MySQL Engine INSERT speed. Читать статью «MySQL и скорость выполнения INSERT для разных типов таблиц» полностью…

Начну сразу с причин, по которым я пишу эту статью. Я периодически просматриваю лог запросов, по которому люди попадают сюда, и вот один из запросов — хранить php сессию в mysql.

Итак, как же хранить PHP-сессии в базе данных? Читать статью «Хранение PHP-сессий в базе данных» полностью…

Специалисты по безопасности, пожалуй, всем уже проели плешь, говоря о том, что все данные, приходящие от пользователя, нужно тщательно проверять… Казалось бы, "азбучные истины", этому должны учить в школе . Мне стало интересно: а многие ли сайты действительно защищены? Читать статью «Безопасность, о которой все так много говорят…» полностью…

Иногда случаются ситуации, когда сессии приходится хранить в базе данных и, что еще хуже, иногда приходится читать данные из сериализованной сессии. Читать статью «Сессии PHP и unserialize()» полностью…