[Безопасность] Список дырявых плагинов

Все уже знают, что очередной релиз WordPress 2.3.3 в основном призван исправить бреши в безопасности (как обычно русскую версию можно скачать у Кактуса), но гарантирует ли это, что на ваш блог не смогут посягнуть?

Можно ответить «Нет», если вы не уверены в тех плагинах, которые у вас установлены.
Например, сами разработчики WordPress настоятельно рекомендуют не использовать плагин WP-Forum, а я несколько расширю этот список за счёт информации с сайта БлогСекьюрити.

  1. WP TextLinkAds
  2. Плагин для размещения ссылок от известной конторы TLA версии ниже 1.1.3 подвержен уязвимости, благодаря которой злоумышленник может получить доступ к БД и компрометировать весь блог.
    Для исправления советуют либо скачать новую версию, либо найти строку 512 ($postId = $postId;) и заменить её на $postId = (int) $postId;.

  3. dmsguestbook
  4. Гостевая книга dmsguestbook вообще одна сплошная дыра. Тут вам и возможность дефейса, получение доступа к данным из wp-config.php, управление файлами и папками на сервере, и даже множественные XSS-уязвимости в купе с различными SQL-инъекциями.
    БлогСекюрити советуют вообще нафиг отключить этот плагин, т.к. даже в последней (1.8) версии много багов и уязвимостей.

  5. st_newsletter 2.x
  6. Плагин рассылки st_newsletter позволяет, применив специальный запрос, содержащий SQL-инъекцию, получить список всех пользователей и хэши их паролей.
    Заплаток пока что нет, так что отключаем плагин от греха подальше.

  7. Wordspew
  8. Относительно известный Live-чат Wordspew тоже подвержен злостным инъекциям, и тоже пока что нет официальных (и не официальных) багфиксов. Отключаем.

  9. wp-footnotes 2.2
  10. Известная добавлялка подписей к постам wp-footnotes тоже обросла уязвимостью, из-за которой «злодей» получает доступ к админ.панели плагина, просто обратившись по определенному УРЛ к сайту. И, следовательно, может «добавить» свой текст к вашим постам.
    И этот плагин без фикса, так что используйте на свой страх и риск.

На этом всё. Надеюсь теперь вы чувствуете себя ещё более защищенными.

[Plugins] Ajax Comments 2.09 (на халяву)

Давненько я не выкладывал никаких плагинов, хотя испробовать успел довольно много.

Так о чём это я? Ах да, наверное найдётся несколько человек, которые скачали и установили мою версию Ajax Comment, но не это главное, а то, что у меня в блоге с определенной периодичностью, при отправке комментария, выдавалась ошибка о «Время истекло. Сервер не ответил вовремя.».

Полез я искать новую версию этого плагина и был обрадован сообщением о «Заплатите $1». И не денег мне было жалко, чтобы ещё пару месяцев назад его купить, просто возможность оплаты была только через PayPal, который было лень регистрировать.

Тут на днях как раз прошёл регистрацию и купил-таки новую (2.09) версию и очень она мне понравилась, перечислю фичи от автора, а самое интересное выделю красным:

  • Не надо ничего изменять в коде шаблонов. Работает сразу после активации.
  • Применяет WordPress Plugin API, поэтому отлично работает с другими плагинами.
  • Проверка капч и валидация форм происходит на стороне сервера, без обновления страницы.
  • Сообщения об ошибке появляются в красном прямоугольнике над формой комментариев.
  • Картинка отправки комментария отлично смотрится с любым дизайном.
  • В архиве содержится подробная документация для любителей покопаться в исходниках.
  • Работает с комментариями на любом языке, благодаря поддержки локализаций и unicode-символов.
  • jQuery fade-эффект, делающий читателей счастливее. 😀
  • 60 сек таймайт на сервере не даст подвиснуть читателям.
  • Протестирован на текущих версиях Firefox, Internet Explorer 6/7, Opera, Netscape, и Safari.

Плагин теперь отлично работает с WP AJAX Edit Comments, который раньше приходилось отключать. Мне даже не пришлось вносить никаких изменений, чтобы плагин начал адекватно работать с капчей, так что всё что я сделал — это перевёл пару строчек ошибок на русский.

И главное, на мой взгляд, что теперь вместо ява-скрипт библиотеки Prototype+Scriptaculous используется более легкий (по размерам) jQuery.

Ну а вот вам и ссылочка на сам плагин Ajax-Comments 2.09 (90 kb), думаю автор не будет сильно плакать, что я его раздаю на халяву, ведь «какой русский не любит халявы», к тому же GNU GPL v2 позволяет мне это делать, я же внёс изменения в исходные коды)))

Сразу оговорюсь — плагин тестировал мало, поэтому прошу в комментах хорошенько его «помучить» и оставить отзывы по работе.

ПыЦ: Плагин работает с WP 2.1 — 2.3.x и WP MU.

Адаптируем тему под WordPress 2.3.x

Обещал, значится, вот и пишу. Если кто-то ожидает «откровений», то думаю несколько напрасно, но для общего развития людям, интересующимся CMS WordPress и желающим идти в ногу со временем, ознакомиться стоит.

Многих людей останавливает от перехода на WordPress 2.3 сам процесс апгрейда до новой версии, и я вполне их понимаю, потому что сталкивался с «кривыми» апдейтами, когда приходилось править «напильником» кодировки или наблюдать округлившиеся глаза после «преобразования категорий в тэги» и фразу «Эээ… а как это сделать обратно?».

Поэтому, если уж обновляетесь, то делайте это правильно, а, если есть возможность, попросите людей знающих. Они это сделают и быстро, и качественно, а то ведь можно и так конвертнуть базу, что «и» и «ш» пропадут и обратно их уже не получить.

Ну а теперь к теме поста. Первым делом определимся с тем, что у нас реально нового появилось в WordPress 2.3 относительно тем: 1. Тэги, 1а. Облако тэгов, 2. Несколько Deprecated тэгов и их новые аналоги.
Пройдёмся по порядку.

1.Тэги.

Да-да, теперь у нас есть встроенные тэги (ура-ура!), а так же несколько тэгов-разметки для работы с ними:
the_tags — выводит все тэги, назначенные посту, используется внутри Loop.
Синтакис простой: the_tags(‘текст ДО’, ‘разделитель МЕЖДУ тэгами’, ‘текст ПОСЛЕ’).
Примеры из кодекса:
the_tags(‘Метки:’, ‘, ‘, ‘<br />’); — выведет текст «Метки:», список тэгов через запятую, а потом перейдёт на новую строку.
Или вот код, выводящий тэги в виде ненумерованного списка the_tags(‘<ul><li>’,'</li><li>’,'</li></ul>’);

get_the_tags — функция возвращает (заметьте, не выводит, а только лишь возвращает) список всех тэгов, назначенных посту, в виде массива объектов. А вы уже с ним можете делать что хотите, т.е. формировать какие угодно конструкции и вводить проверки, работая с каждым тэгом в отдельности. Работает только в Loop.
Вот пример того, как выводить тэги в виде картинок, с соответствии с названием (стоит понимать, что картинку нужно положить в папку ДО применения тэга):

Всё просто, во второй строке мы сохраняем в переменную posttags все тэги данного поста, в третьей проверяем попался ли нам хоть 1 тэг (вот, кстати, и ещё одно применение get_the_tags() — проверка на существование тэгов, пример будет чуть позже), в четвёртой строке начинаем выдёргивать по очереди все тэги и с 5 по 9 строку выводим картинку в ссылке.
В принципе строки с 6 по 9 можно объединить в одну, это я чтобы в блоге за края не уезжало.

А вот этот коротенький код будет выводить тэги только тогда, когда они есть. Желательно использовать в том случае, если вы обновляли свой блог с более ранней (<2.3) версии и не успели "пометить" все посты, в таком случае пользователь не будет удивлён строчкой "Метки:" и пустым пространством за ним.

Ну и чтобы закончить с get_the_tags(), вот список параметров, которые можно получить через $tag->параметр:

  • term_id — id тэга
  • name — имя
  • slug — сокращение, сгенеренное из имени. Если вы используете RusToLat, то генериться он будет в транслите.
  • count — общее количество раз, которые тэг встречался в блоге.

single_tag_title — функция выводит/передаёт в переменную, заголовок страницы тэга, т.е. той, которая будет доступна при просмотре всех постов с определенной меткой (/tag/wordpress). Я кончено могу и ошибаться, но это 100% аналог тэга single_cat_title, причём, если вы применяете последний, то он адекватно будет выводить и заголовки для тэгов, а не только категорий.

1а. Облако Тэгов

До меня уже Максим подробно описал работу с облаком тэгов, поэтому просто процитирую его:

Для того, чтобы вывести облако меток, например в сайдбаре нужно использовать функцию wp_tag_cloud(). Функция принимает следующие аргументы (указаны значения по-умолчанию):

  • ‘smallest’ => 8 (минимальный размер шрифта)
  • ‘largest’ => 22 (максимальный размер шрифта)
  • ‘unit’ => ‘pt’ (единицы измерения)
  • ‘number’ => 45 (количество меток в облаке)
  • ‘format’ => ‘flat’ (разделитель: flat — пробел, list — список, array — массив)
  • ‘orderby’ => ‘name’ (сортировка: name — по имени, count — количеству записей)
  • ‘order’ => ‘ASC’ (порядок сортировки: ASC — прямой, DESC — обратный)
  • ‘exclude’ => » (исключить метки, указываются через запятую)
  • ‘include’ => » (включить метки, указываются через запятую)

Полезность для работы с тэгами.

Если кто ещё не знает о существовании такого мега полезного плагина как Simple Tags, то могу только… посоветовать его немедленно скачать и установить! Так же не забываем благодарить тов. Лекактуса за качественную локализацию и своевременные обновления.

Что может плагин (взято у Лекактуса):
Simple Tags — это ПРЕВОСХОДНЫЙ инструмент для управления вашими метками WP 2.3.
Он был написан со следующей философией: лучше производительность, больше безопасность и преподнесение новых функций!

  • угадывает метки при вводе и подставляет из существующих
  • автоматические подходящие метки для записи
  • управление метками (переименование,удаление объединение, поиск и добавление меток, редактирование коротких ссылок меток)
  • список непомеченных страниц/записей
  • массовое редактирование меток
  • возможность добавлять метки в страницы (не только записи) и включение их в результаты поиска по меткам
  • связанные записи по общим меткам
  • возможность добавлять связанные записи в RSS
  • динамические облака меток с раскрашиванием в виджетах
  • метки внутри заголовка блога
  • поддержка встраиваемых меток ([tags]tag1, tag2[/tags]) для совместимости со старыми записями, где они были заданы таким способом
  • Автоматическая вставка меток а записи (опционально, без редактирования шаблона). А также на выбор включение их только на блоге/в rss или в оба места сразу

О том, как всё это настраивать, написано ОЧЕНЬ подробно на странице плагина.
А ещё я советую вам пролистать блог Лекактуса на наличие кучи полезных плагинов и подписаться на рсс, чтобы следить за их обновлениями.

Deprecated тэги/функции и их новые аналоги

Небольшое отступление перед тем, как перейти непосредственно к самим тэгам. Если вы не знаете что, такое Deprecated (нежелательные) элементы в программировании, то в кратком виде статья с wikipedia:

Часть программы или метод, обозначенный как deprecated, являются сомнительными, и использование их в дальнейшем необоснованно. Эта часть работает в текущей версии ПО, однако может вызывать сообщение об ошибке в качестве предупреждения. Это служит для предупреждения пользователя о том, что данная часть кода может быть удалена в следующих резлизах программы.

Основной причиной объявления части кода (функций, методов, классов) как deprecated является желание улучшать код, и, при этом, со временем избавляться от устаревших подходов. Оставление старого кода наряду с новым приводило бы к неоправданному разрастанию программного продукта, что усложняло бы его поддержку, изучение и использование. В то же время, просто удалять устаревшие части кода нежелательно, так как это нарушит обратную совместимость для пользователей данного ПО.

Короче, никто не гарантирует, что те тэги/функции, которые были помечены deprecated после релиза WordPress 2.3, вообще будут работать, а уж тем более каждая новая версия (а 2.4 уже вот-вот будет доступен) увеличивает шанс, что тэги будут выдавать ошибку или работать не верно. Поэтому просто-напросто, нужно просмотреть свою тему, найти все вхождения «нежелательных» тэгов и поменять их на новые.

Тэги работы с ссылками из блогролла

get_links_list — вывод всех пунктов блогролла в виде не нумерованного списка.
wp_get_links — выводит ссылки из определенной категории блогролла, в виде списка.
get_links — настраиваемое отображение ссылок из блогролла.

На смену этим тэгам-разметки пришла (причём ещё в 2.1 версии, но запретили их только сейчас) функция wp_list_bookmarks(), которая делает всё тоже самое, только лучше.

Если использовать wp_list_bookmarks() без параметров, то на выходе получим список ссылок из блогролла, разбитые по категориям, отсортированные по имени, с картинкой, если она указана; так же в ссылке будет описание в title, взятое из соответствующего поля; рейтинг указан не будет.
Понятное дело, что параметров уйма:

  • categorize — разбивать ли ссылки по принадлежности категории? 1 — Да, 0 — Нет.
  • category — ID категорий через запятую, которые нужно отображать.
  • category_name — тоже самое, что и category, но указываются имена категорий.
  • category_orderby — по какому полю сортировать категории. name — имя (по-умолчанию) или id.
  • category_order — порядок сортировки по предыдущему параметру. ASС и DESC соответственно.
  • title_li — указываем текст, который будет выведен перед всеми ссылками, если параметр categorize=0. По-умолчанию выводится «Bookmarks», но если указать пустое значение (title_li=), то ничего выведено не будет, в том числе и <ul>, и </ul>.
  • title_before и title_after — два параметра определяющие обрамление описания (decription) категорий, при categorize=1. По-умолчанию обрамляются заголовком второго уровня (<h2></h2>). Если меняете один из этих параметров, то не забудьте заменить и второй.
  • show_private — параметр определяющий, можно ли отображать «приватные» ссылки. Если установлено значение 1, то игнорируются админские настройки и выводят даже личные ссылки.
  • include и exclude — позволяют точно указывать, какие ссылки (по ID) показывать/не показывать.
  • orderby — это уже сортировка ссылок, а не категорий, тут вариантов больше: id, url, name, target («Назначение» в русской версии), description (описание), owner (владелец ссылки, т.е. тот кто её добавил), rating, updated (дата последних изменений), rel («Отношение к ссылке»), notes («Заметки»), rss, length (сортировка в зависимости от длинны ), rand (в случайном порядке).
  • order — порядок сортировки по предыдущему параметру. ASС и DESC соответственно.
  • limit — количество ссылок, которые будут показаны. Параметр -1 отобразит все ссылки, удовлетворяющие остальным параметрам, он же и стоит по-умолчанию.
  • before, after, category_before, category_after — обрамление каждой ссылки и каждой категории (не описания, как в случае с title_before и title_after). По умолчанию в обоих случаях стоят <li>, и </li>, причём в <li> категории дописывается соответствующий ей id и class.
  • between — параметр, определяющий разделитель, между ссылкой/изображением и соответствующим описанием, по умолчанию стоит перевод на новую строку (‘\n’).
  • show_images — показывать ли изображение, если оно указано в соответствующем поле. 1 — Да, 0 — Нет.
  • show_description — показывать описание к ссылке или нет.
  • show_rating — отображать ли рейтинг.
  • show_updated — указывать ли дату и время последнего обновления.
  • hide_invisible — выводить ли ссылки помеченные как «невидимые»? В данном случае 1 — Нет, 0 — Да.
  • echo — выводить ли сразу в шаблон или просто вернуть значение в переменную (чтобы ещё мучать при помощи PHP). 1 — Да, 0 — Нет.

Фуф, осилили? Ну, тогда для самых стойких небольшой пример — код выводит ссылки из рубрики ID=2, используя при этом картинки, обрамленные в и без описания. В добавок всё отсортированно по URL ссылки.


Ну что же, вроде основные моменты в адаптации темы под WordPress 2.3.x я описал, остальное в ваших руках.

Если что-то осталось непонятным или после прочтения возникли вопросы, то не стесняемся и спрашиваем в комментариях. Хотелось бы узнать, полезно ли будет описать остальные Deprecated тэги и их аналоги, для тех, кто переходит с 2.0.x на 2.1 и выше?

Желаю успешного, а главное безглючного перехода на WordPress 2.3.

Быстрее-легче-стабильнее или “немного” о Wp-Super-Cache.

Почему-то, как мне показалось, довольно тихо прошло появление очередного «всесильного всемогущего сокращающего время загрузки и нагрузку на сервер» плагина WP-Super-Cache, а ведь за бугром о нём только ленивый не писал и даже успели отDiggать страницу плагина почти тысячу раз. Поэтому, думаю, стоит всё же приглядеться и пощупать это чудо программерской мысли.

Итак, что же может этот плагин, для чего/кого он предназначен и чем лучше аналогичных стандартных и не очень средств кэширования?


Введение
Большинству пользователей WordPress’а известен прекрасный плагин WP-Cache 2. Он кэширует страницы блога и отдаёт их по запросу без обращения к базе данных. Несмотря на это, всё же приходится подгружать определенный php-код, чтобы обслуживать уже кэшированные страницы, чтобы там не говорили на странице о wp-cache (прародитель wp-cache2)

WP Super Cache действует по другому принципу. После установки, создаются html файлы, и они отдаются браузеру без единого вызова php. Насколько быстро ваш сервер отдаёт картинки? Почти так же быстро он будет выдавать и кэшированные страницы. Если вашему сайту ежедневно приходится справляться с массированным потоком посетителей или периодически испытывать Дигг-эффект, то этот плагин для вас.

Как оно работает то?
Как обычно действуют люди, подготавливая свой сайт к массовому паломничеству с дигга? Они в ручную сохраняют копию страницы, которая теоретически будет генерить основной траффик, и помещают её в папку соответствующую пермалинку. Этот метод помогает серверу выдерживать большие нагрузки и не «умирать», но эффективность его напрямую зависит от возможности предсказывать потоки пользовательского интереса к страницам. Сам по себе WP-Cache хоть и полезен, но в определенных ситуациях не совсем адекватен, тогда как WP Super Cache как раз и был создан, чтобы воссоздавать этот процесс автоматически.

Когда к странице обращается незалогиненый посетитель или он не оставляет комментариев, то сервер отдаёт ему статическую html-страницу из подпапки supercache, которая создаётся в cache папке WordPress. Если вы зайдёте в эту папку (например по фтп), то обнаружите точную копию своей пермалинк структуры в виде папок и отдельные html-файлы в каждой из них. Чтобы убедиться, что страница создана плагином, достаточно просмотреть её исходный код и вы обнаружите там следующую строку в самом конце <!— super cache —> или <!— super cache gz —> для сжатого варианта.

Залогиненым же пользователям или тем, кто оставит комментарий, будет показана кэшированная страница, созданная средствами стандартного WP Cache, где в конце будет значится <!— Cached page served by WP-Cache —>.

Фишки/Отличия от WP-Cache

  • Собственная система hook’ов, для более тонкой настройки кэширования (важно только разработчикам).
  • Прекрасно работает и с WordPress MU в VHOST и не-VHOST конфигурациях. Файлы каждого блога кэшируются независимо друг от друга.
  • Стандартные файлы WP-Cache разбиты на 2 части. Мета-файлы теперь располагаются в отдельной папке, что увеличивает скорость обращения к ним и определения необходимости обновления кэша.
  • Встроена заплатка для WP-Cache при работе с защищенными постами.
  • Автоматически отключает gzip-сжатие в WordPress вместо того, чтобы «умереть».
  • Улучшена работа с Akismet и иными плагинами борьбы со спамом — кэш будет обновлен, только если комментарий 100% не спам.
  • Кнопка «lock down» (защёлкнуть) — подготавливает сайт к мощному наплыву посетителей. После включения «защёлкивает» статичные кэш файлы и не удаляет их после добавления нового комментария.
  • Автоматическое внесение изменений в .htaccess (Не забудьте сохранить свой .htaccess перед установкой плагина).
  • Не кэшируются запросы с GET-параметрами.
  • Улучшенная проверка совместимости wp-cache-config.php и advanced-cache.php, если вы пользовались старой версией.
  • Улучшена поддержка Microsoft Windows.
  • Правильно работает с кэшированными страницами в ОС Red Hat/Cent или других, содержащих запись для gzip в /etc/mime.types.
  • Функция «Не кэшировать следующие адреса» теперь может использовать регулярные выражения.

Минусы

  • Если вы залогинен или оставили комментарий, вы никогда не увидите super-cache страницу. Вам всегда будет выдаваться старый-добрый WP-Cache. Это не так уж и плохо, так как большинство ваших посетителей никогда не оставляют комментарии.
  • Для работы со статическими страницами используется Mod Rewrite Апача, поэтому необходимо, чтобы он был активирован на сервере.
  • Особо динамичные части вашего сайта не будут обновляться так быстро, как хотелось бы. Например, виджет — последнии комментарии.
  • Некоторые хостинги испытывают проблемы при работе со сжатыми html-файлами, т.ч. может потребоваться дополнительная настройка.
  • Не рассчитывайте, что дешевый хостинг выдержит большой всплеск трафика, даже если страницы будут кэшированы.
  • Помните, что динамический контент, вроде того, который размещается в сайдбаре, будет обновлен только когда будет обновлена кэшированная страница. Время до обновления можно настроить, но кэшированные файлы будут удалены лишь в том случае, если у вас будет смесь из статических и динамических запросов.
  • Некоторые плагины, такие как SK2, Bad Behaviour и другие, работа которых зависит от «свежести» данных, могут работать не совсем корректно, во всяком случае, до тех пор, пока эти плагины не будут специально оптимизированны для очищения кэша в нужный момент.

(с) Автор Плагина


Это всё конечно интересно и красиво на словах, но работает ли оно в действительности? Сам я не мастер нагрузочного тестирования, поэтому приведу выкладки других людей.

Во-первых, автор плагина ставит в пример себя — после анонса Wp-Super-Cache на дигге, посещения скакнули до 4700 пользователей, что прямо скажем не мало. И вот какие графики получились — первый нагрузка на процессор, второй — посещения.
wp super cache plugin cpu graph
wp super cache plugin visits graph
Отчётливо виден момент активации кэширование (падение нагрузки на процессор), а так же приятно наблюдать, что рост посещений никак не сказывается на процессоре.

Во-вторых, некий Роберт провёл замеры производительности для 1000 запросов. Тестировал по локальной сети, на сервере (P4 — 3Ghz, 2GB RAM) поставил чистый ВордПресс и с другой машины делал запросы.

Результаты:
а) стандартный WordPress без кэша:
— время на тест — 161 сек;
— запросов в секунду — 6.21/сек
— время на 1 запрос — 161 мсек
— скорость передачи — 31.07 Kbytes/сек

б) WordPress + Super Cache:
— время на тест — 5.718750 сек;
— запросов в секунду — 174.86/сек
— время на 1 запрос — 5.719 мсек
— скорость передачи — 898.62 Kbytes/сек

в) WordPress + Super Cache + eAccelerator:
— время на тест — 2.531250 сек;
— запросов в секунду — 395.06/сек
— время на 1 запрос — 2.531 мсек
— скорость передачи — 2030.22 Kbytes/сек

Думаю, комментарии излишни.

Включил сейчас плагин на этом блоге, на пару минут для теста активировал gzip-сжатие и проверил, как реагируют браузеры. С Оперой и ФФ всё ок, а ИЕ6 как обычно отличился — предложил сохранить локально .html.gz страничку) Чтобы не пугать людей, сжатие отключил, но вообще нужно будет разобраться почему ИЕ так отреагировал.

Плагин в установке достаточно прост, особенно если следовать рекомендациям в readme :-), а вот настройка для тех, кто не видел до этого Wp-Cache2, возможно покажется непонятной. С другой стороны Wp-Super-Cache довольно специфическая вещь и не факт, что окажется востребованным.

Хотелось бы узнать — нужно ли отдельным постом расписывать установку и настройку?


Кстати, курсовая и 2 из 4 экзамены сданы на отл., что ещё немного приближает ко второму красному диплому :p
Заинтересовался я тут eAccelerator, интересно, удастся ли мне поставить его на виртуальную площадку у МастерХоста. Если да, то напишу как и что я делал.
Удачного дня и побольше Дигг-эффектов.