Я не приверженец Movable Type (я использую WordPress), да и вообще веб-приложений, написанных на языках, которые я плохо знаю. Но читатели в комментариях к статье про тюнинг WordPress-блогов убеждали меня, что это — «замечательная платформа, которая всегда впереди WP по многим пунктам.» Я решил всё-таки проверить это, тем более на днях вышла новая официальная русская версия.

Идём на русский сайт MT и качаем архив с последней версией движка. Распаковываем в какой-нибудь каталог, в который есть доступ у веб-сервера. В моём случае это Apache 2.2.8 (httpd) и каталог /home/www/mtblog. Можно попробовать после этого открыть в браузере этот каталог (адрес зависит от настроек веб-сервера), в моём случае — http://localhost/mtblog/. Страница приветствия уже работает, но это пока всё.

Читать далее »

Предлагаю небольшое исследование на тему безопасности веб-приложений и фильтрации вводимых данных. Скорее всего, я ещё вернусь к этой теме, но сейчас больше хочется не писать трехтомник, а сохранить и упорядочить собранное и проверенное. В частности, речь пойдёт о фильтрационной защите от XSS-атак и SQL-инъекций.

В PHP есть ряд специальных функций для работы со строками, применимых для этой цели. Вот они:

strip_tags() — вырезает теги HTML и PHP из строки.

htmlspecialchars() — конвертирует только специальные символы (‘&’, ‘»‘, »’, ‘<‘ и ‘>’) в HTML сущности (‘&amp;’, ‘&quot;’…). Используется для фильтрации вводимых пользователем данных для защиты от XSS-атак.

htmlentities() — конвертирует все символы в строке (кроме букв) в мнемоники HTML. Используется для защиты от XSS, являясь более гибким аналогом htmlspecialchars.

stripslashes() — удаляет заэкранированные символы (после преобразования в сущности предыдущими функциями их незачем экранировать). Обычно используется в связке с проверочной функцией get_magic_quotes_gpc(), показывающей текущую установку конфигурации magic_quotes_gpc.

Эта конфигурация влияет на то, как будут обрабатываться специальные символы, содержащиеся в данных, передаваемых пользователем (массивы $_GET, $_POST, $_COOKIE). При magic_quotes_gpc = 1 эти спецсимволы (одиночные и двойные кавычки, обратный слэш, байт NULL) автоматически экранируются. При magic_quotes_gpc = 0 все данные передаются в таком виде, в каком их ввел пользователь. В последнем случае в целях безопасности требуется обрабатывать передаваемые данные.

mysql_real_escape_string — мнемонизирует специальные символы в строке для использования в операторе SQL с учётом текущего набора символов в кодировке соединения. Иными словами, функция превращает любую строку в правильную и безопасную для MySQL-запроса. Используется для очистки всех данных, передающихся в MySQL-запрос для защиты от SQL-инъекций.

На основе этих данных, можно собрать функцию для однозначной очистки непроверенных данных. Эта функция получает две переменные — строку с введёнными символами и булево значение для определения — требуется ли приведение к MySQL-запросу. Возвращает функция очищенную строку. Конечно, это не панацея, но функцию легко изменить под собственные нужды.

InputClear.phps - фильтрация введённых пользователями данных.

Если кто-то обнаружит ошибки, или знает способ лучше — добро пожаловать в комментарии, мне очень интересно.

Жилинский Владимир.

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

Начнём с сайта. Среднестатистический сайт — это набор файлов на диске и база данных, как правило — MySQL.

С базой данных особых проблем не вижу:

• для WordPress есть плагин WordPress Database Backup , который сохраняет базу по расписанию и отправляет её на e-mail
• для других систем можно воспользоваться скриптом Sypex Dumper , или настроить дамп и отправку по почте самостоятельно (несколько строк кода).

С сохранением файлов сайта чуть сложнее. Можно просто периодически сохранять их вручную, но можно и автоматизировать.

Сначала заархивируем все файлы сайта в один архив с помощью библиотеки PclZip :

<?php require_once('pclzip.lib.php');
$date = date('Y-m-d');
$archive = new PclZip("$date.zip");
$v_list = $archive->add('../');
if ($v_list == 0) { die("Error : ".$archive->errorInfo(true)); }

В этом примере $v_list — это относительный путь к архивируемому каталогу или список каталогов и фалов через запятую. Выбирайте сами, что именно нужно резервировать.

После этого можно сделать дамп MySQL базы и добавить его в этот архив, а потом, например, отправить полученный архив по почте с помощью класса PhpMailer и удалить его чтобы не занимал место. Запускать этот процесс можно с помощью планировщика у хостинг-провайдера (у Majordomo бесплатный) или (если это WordPress) с помощью WP-Cron .

Законченного решения я не выложил, но конструктор укомплектован — собирайте кому что нужно, все части надёжны и проверены.

Следующий эпизод — локальный компьютер. Тут стоит сразу определиться — что именно резервировать. Для больших и редко используемых файлов (фото, видео, архивы) я поставил себе под стол старенький компьютер под Ubuntu, настроил NFS и забыл о нём — приходя домой я получаю доступ к этим файлам, а в крайнем случае — можно и удалённо залезть.

А для регулярного бэкапа текущих проектов вполне подойдёт Gmail. Бесплатный почтовый ящик вмещает до 10Gb данных, а самый интересный фокус в том, что его можно подключить как обычный диск — как в Linux , так и под Windows . А сохранять туда нужные файлы тоже можно кроном, или его Windows-аналогом — nnCron + nnBackup .

А заодно посмотрим, что об этом думают другие участники конкурса на лучший способ бэкапа личных данных.

Жилинский Владимир.