|
Спонсор поста: деревообрабатывающая промышленность, продажа леса
Вступление.
Собственный движок блога обладает многими преимуществами. В нем можно поменять вообще все, до мелочей и уйдет на это в 10 раз меньше времени, чем ковыряться в чужих движках, таких как WordPress или DLE (DLE особенно страшен в этом плане на мой взгляд). Для него легко поставить собственный дизайн. К нему легко прикрутить собственные другие наработки, например, портал, каталог статей и прочее.
Большим плюсом номер два я считаю невозможность взлома собственного движка. Ведь для взлома уникального, нигде больше не установленного движка хакеру придется поломать голову. А вот для стандартных движков обычно делают даже так называемые эксплойты – скрипт, запустив который, даже безмозглый 12летний идиот может получить пароли от админки Вашего блога.
Да, это палка о двух концах – если плохо написать движок с точки зрения безопасности, ломаться он будет довольно легко. Но я лично не собираюсь писать его плохо  А Вы?
Еще плюсы? Например, скорость работы. Тот же огромный и «тяжелый» WordPress будет работать в разы медленнее, чем заточенный под конкретные задачи собственный движок.
Я расскажу, как написать свой движок за пару часов. А если копировать код у меня из статьи – за 15 минут. А если сразу скачать исходник – за 30 секунд 
(тут поясню: у меня блог на стандартном движке, т.к. я его веду уже больше полугода и мне не хочется возиться с переносом статей на собственный движок; жаль, что я не начал вести блог на своем движке с самого начала)
Недостатки есть?
Есть, не без этого. Главным недостатком своего движка и огромным плюсом для стандартных движков я считаю плагины. То есть для собственного движка их просто нет и быть не может, пока автор движка сам их не напишет. Например, в WordPress можно за 1 минуту установить плагин для вывода последних комментариев, вывода смайликов, голосования (и вообще чего угодно), а в своем блоге придется писать это все самому. И если вывод последних комментариев и смайликов – задача не сложная, то, например, с голосованием уже посложнее.
Зачем Вам все это?
В любом случае, даже если Вы выбираете стандартный движок, я все равно рекомендую прочитать статью – особенно начинающим программистам. Эта статья фактически описание создания несложной CMS, которую можно превратить из блога во что угодно
И еще момент. После этого небольшого цикла статей я напишу, как сделать генератор сателлитов! И по плану – там как раз пригодится этот собственный движок Запахло деньгами?
Составляем ТЗ.
(ТЗ – Техническое Задание, документ, по которому программист пишет программу, скрипт, сайт и т.п.)
Даже в таком несложном деле лучше составить небольшое ТЗ и не отходить от него в процессе разработки. Мы просто опишем, что хотим видеть в движке, а потом сделаем ровно так, как написали. Я считаю, что это полезная практика – иначе можно «расплыться» (захотеть сделать и то и се и пятое и десятое, в итоге не сделать ничего или сделать частично и плохо).
«Нужны возможности: 2* добавлять категории, редактировать их названия, вывод категорий по алфавиту, вложенность не нужна. Добавлять, редактировать или удалять посты. В посте есть заголовок и основной текст. Визуальный редактор не нужен, разрешить HTML-теги. 3* Возможность комментировать пост, вводя имя, почту, сайт и комментарий. Регистрация пользователей не нужна. Все адреса в виде ЧПУ (человеку понятный URL, а-ля lamara-nsk.ru/hello.html). Категории открываются по адресам /category/catname/, где catname – имя категории. Посты открываются по адресам /postname.html, где postname – адес поста. Эти адреса тоже можно редактировать. *4 Прикрутить RSS последней версии протокола. Весь блог в кодировке UTF-8. Все изменения администратор вводит через админку по адресу /vrotmnenogi-admin/. Добавить постраничный вывод постов.»
Вот такое тех-задание. Сделаем четко по нему
Я решил разделить создание собственного движка блога на четыре части – первая – это проектирование и еще три отмечены звездочками в ТЗ [сначала хотел 3 части, но эта статья уже вышла довольно большой, а для понимания читать большую статью, я думаю, тяжеловато]. У меня еще нет готового движка (на момент написания этих строк), поэтому исходник каждый раз будет все более дополняться.
Начнем с начала.
В начале работы я обычно прикидываю, какие мне нужны таблицы в базе данных и как их будет использовать движок. Например, здесь. Я перечислю поля и тип данных в них записываемый, а также объясню – для чего то или иное поле. Для простоты мы будем использовать только int и text.
Категории:
id (int auto increment) | url (text) | title (text)
id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор категории
url – адрес категории, который будет подставляться /category/сюда/
title – название категории, которое будет выводиться в браузер
Посты:
id (int auto increment) | url (text) | title (text) | post (text) | dt (datetime)
id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор поста
url – адрес поста, который будет подставляться /сюда.html
title – заголовок поста, выводится в браузер
post – содержимое поста, выводится туда же
dt – дата и время написания поста, проставляется автоматически и изменению не подлежит
Комментарии к постам:
id (int auto increment) | post_id (int) | nick (text) | email (text) | site (text) | comment (text) | ip (text) | dt (datetime)
В ТЗ ничего не сказано про запись IP комментатора, но я считаю, что это необходимо. Может помочь отловить злого спамера или забанить по IP. В общем, если «враг» появится, лучше знать про него как можно больше.
id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор комментария
post_id – идентификатор поста, к которому написан комментарий
nick – имя комментатора (никнейм)
email – почта комментатора
site – сайт комментатора
comment – сам комментарий
ip – IP-адрес комментатора
dt – дата и время написания комментария. Так. Для протокола.
Знатоки из Что-Где-Когда, конечно, заметили бы, что IP адрес можно хранить в виде long-числа, а я храню его в виде текста. Я считаю, что так нагляднее и вообще редко храню его в виде числа. Говорят, что по использованию памяти это лучше, не знаю, я не замерял. Но знаю, что это хуже по производительности – нужно преобразовывать число в IP и обратно. Я так не делаю, в общем.
С базой данных все. Теперь пара слов о ЧПУ.
Из ТЗ видно, что должны быть ЧПУ (человеку понятный Url). Для этого нам нужно создать .htaccess, который мог бы разбирать адреса вида /category/name/ и /post.html и передавать в скрипт значения этих полей в виде переменных. Например, пусть имя категории передается в переменной category, а имя поста в переменной post из массива $_GET.
Заметьте, нужно предусмотреть и постраничный вывод! Лучше подумать об этом сразу. Я предлагаю сделать примерно так же, как сделано в WordPress. А именно, для категорий страницы показываются по адресу /category/name/page/1/, где 1 – номер страницы. А если категория не выбрана (главная страница), то адреса для вывода страниц будут иметь вид /page/1/ – прямо от корня.
И еще нужно предусмотреть зарезервированное имя для RSS. Я предлагаю сделать простой адрес: /rss.html, почему бы и нет?
Какой же .htaccess файл нам понадобится? Я бы сделал такой:
RewriteEngine On
1 RewriteRule ^(rss).html$ rss.php [L]
2 RewriteRule ^([A-Za-z0-9_]+).html$ index.php?post=$1 [L]
3 RewriteRule ^(category)/([A-Za-z0-9_]+)/$ index.php?category=$2 [L]
4 RewriteRule ^(category)/([A-Za-z0-9_]+)/(page)/([0-9+])/$ index.php?category=$2&page=$4 [L]
5 RewriteRule ^/(page)/([0-9+])/$ index.php?page=$2 [L]
Я пронумеровал строки. В рабочей версии нумерации, конечно, нет.
Строка 1. Перекидывает с rss.html на rss.php прозрачно для пользователя. В rss.php будет генерироваться сама RSS.
Строка 2. При открытии адреса вида /some.html передает все между слешем и .html в скрипт index.php в переменной $_GET['post'];
Строка 3. При открытии категорий (адрес вида /category/имя/) передает в скрипт index.php имя категории в перменной $_GET['category'];
Строка 4 и строка 5 – аналогичное действие, только для других видов URL.
Ключ L не позволяет серверу идти дальше по списку, если нужное нам совпадение с адресом найдено.
Между прочим, здесь есть еще один большой плюс: с помощью регулярных выражений мы задали конкретные символы, которые можно использовать в адресах. Если хакер попытается ввести в адрес не буквенно-цифровой символ, то сервер прервет запрос сразу же. То есть заботиться об этом в самом движке уже не надо.
На этом с «проектированием» покончено, ровно как и с первой частью. В следующей статье мы сделаем добавление категорий, их редактирование, вывод. Добавление постов, их редактирование и отображение.
Пока что все. Всем удачи и до связи Подписывайтесь на RSS, а то что за дела ))) Я еще не набрал даже сотни подписчиков, жуть! ))
__________________________
Посмеялся ))
Оставьте свой комментарий
|
14.08.2008 в 7:22 пп
14.08.2008 в 9:21 пп
14.08.2008 в 9:41 пп
Может все же: RewriteRule ^rss.html$ rss.php [L]
14.08.2008 в 10:21 пп
15.08.2008 в 12:50 дп
15.08.2008 в 2:39 дп
16.08.2008 в 3:02 пп
> id (int auto increment) | url (text) | title (text) | post (text) | dt (datetime)
17.08.2008 в 11:22 дп
17.08.2008 в 10:15 пп
18.08.2008 в 1:16 пп
Статью прочитал, чтобы лучше понять структуру CMS, за это спасибо
19.08.2008 в 4:07 пп
Ну, это уже зависит от умения программиста грамотно защитить свой скрипт.
Не стоит путать понятия хакеров и скрипт-кидди. В любом случае, хакер ломает мозг, ибо ситуации бывают разные.
Порой, даже коммерческие движки легче поддаются взлому, чем их опенсорс аналоги.
19.08.2008 в 4:32 пп
19.08.2008 в 5:29 пп
с этим, пожалуй, не соглашусь =\
не все хакеры несут говно народу. не все творят годости, как вы говорите. не нужно грести всех под одну лопату, это глупо
19.08.2008 в 5:33 пп
19.08.2008 в 6:07 пп
25.08.2008 в 1:23 дп
НИКОГДА нельзя доверять данным, получаемым со стороны клиента! Ибо их можно подделать.
Лучше сразу предвидеть все возможные ситуации и защитить скрипт правильно. Один из способов, проверять по регулярному выражению переменные $_GET['post'], $_GET['category'], $_GET['page']:
// сделал перенос строк, чтобы не съезжал диз
if(eregi(«[^a-z0-9_-]«,$_GET['post']) ||
eregi(«[^a-z0-9_-]«,$_GET['category']) ||
eregi(«[^0-9]«,$_GET['page']))
{ die(‘некорректные данные’); }
// php code
http://raz0r.name/mysli/kak-nuzhno-proveryat-vxodyashhie-dannye/
http://raz0r.name/mysli/proveryajte-tip-dannyx/
http://raz0r.name/releases/funkciya-dlya-obrabotki-vxodyashhix-dannyx/
25.08.2008 в 4:41 дп
25.08.2008 в 2:53 пп
специально для вас написал пост, в котором привел пример
25.08.2008 в 4:21 пп
25.08.2008 в 4:34 пп
> ведь кавычка не входит в разрешенные символы в .htaccess
да, это так, но только при запросах вида /category/catname/.
А если взломщик введет такой урл – index.php?category=’ – здесь правила .htaccess НЕ ПРИМЕНЯЮТСЯ, ибо в нем прописано правило, в котором урл преобразуется по такой маске /category/catname/. Запрос вида index.php?category=’ не подходит под эту маску, поэтому .htaccess его проигнорирует.
25.08.2008 в 5:21 пп
25.08.2008 в 5:24 пп
> то взломщик не может знать, какая именно переменная отдает URL категории, верно?
Верно. Взломщик просто угадывает название переменной.
25.08.2008 в 5:41 пп
21.01.2009 в 4:02 пп
31.10.2009 в 6:13 пп
22.12.2009 в 11:24 пп
>>isfuck
и да!
Трабла чтобы двжок был шустрым и надёжным.
а придерживаясь даже тривиальных понятий безопасности и думая прежде всего головой а также mount /dev/руки , свой движок будет вразы устойчив к взолому чем готовые решения
29.04.2010 в 10:07 пп
ТЗ никогда не писала. Обычно пишу на кусочке бумаги только структуру таблиц БД и сразу же их создаю. Потом стол завален кусочками бумаги..
Вообще примерно так, как вы описываете.
20.06.2010 в 1:48 пп
Автору респект за статью, если б лет на 5 раньше её прочитал, то много подводных камней при разработке движка избежал!
14.07.2010 в 3:47 пп