XML - это не язык программирования, и вам не нужно быть программистом, чтобы использовать или изучать его. XML облегчает компьютеру задачу создания и чтения данных, обеспечивая при этом однозначность их структуры. XML позволяет избежать распространенных ошибок проектирования языков: он расширяем, независим от платформы, включает поддержку интернационализации и локализации. XML полностью совместим с Unicode .

Разработчики php предлагают обрабатывать отдельные элементы XML-документа функциями php. Пример из руководства по php:

"B", "EMPHASIS" => "I", "LITERAL" => "TT"); // Функция для начала тега (может выводить сложный текст, но в данном примере выдаёт // просто соответствующий тег). function startElement($parser, $name, $attrs) { global $map_array; if ($htmltag = $map_array[$name]) { print "<$htmltag>"; } } // Функция для конца тега function endElement($parser, $name) { global $map_array; if ($htmltag = $map_array[$name]) { print ""; } } // Функция для текста (текстового узла) function characterData($parser, $data) { print $data; } $xml_parser = xml_parser_create(); // use case-folding so we are sure to find the tag in $map_array xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, true); xml_set_element_handler($xml_parser, "startElement", "endElement"); xml_set_character_data_handler($xml_parser, "characterData"); // Чтение XML-файла if (!($fp = fopen($file, "r"))) { die("could not open XML input"); } while ($data = fread($fp, 4096)) { if (!xml_parse($xml_parser, $data, feof($fp))) { die(sprintf("XML error: %s at line %d", xml_error_string(xml_get_error_code($xml_parser)), xml_get_current_line_number($xml_parser))); } } xml_parser_free($xml_parser); ?>

Данный пример можно расширить, добавив массив имён тегов, которые будут обрабатываться иным образом, и соответствующие условия в функции startElement и endElement.

Код выглядит просто ужасно. Для использования в преобразовании XML в HTML-страницы он практически непригоден, хотя кое-где применялся, например на сайте How IT works . Конечно, можно писать собственные автоматизаторы, которые читали бы конфигурационные файлы и создавали массивы, но по суммарным трудозатратам выгоднее использовать мощные классы шаблонов, такие как Smarty.

Работа над этим проектом началась ещё в 1999 году, когда группа разработчиков начала писать спецификацию движка шаблонов. Определив, что он должен делать, разработчики пытались написать модуль на C, но в конце концов решили, что лучше сделать класс на php, доступный и понятный всем разработчикам сайтов.

Сейчас Smarty - один из проектов PHP, его сайт находится на сервере PHP по адресу smarty.php.net .

Формально Smarty - класс шаблона. На самом же деле, его функциональность на порядок выше, чем у множества *Template.

Во-первых, Smarty производит не только вставку переменных в шаблон, но и выполняет php-код в самом шаблоне. Во-вторых, шаблоны в Smarty преобразуются в php-скрипты, и всю грязную работу по вставке переменных в текст и выполнению логических конструкций отдаёт встроенному в php парсеру. Эти php-скрипты при включённом кешировании сохраняются в файлы, которые вызываются при следующих обращениях к шаблонам. Когда шаблоны меняются, скрипты генерируются снова. Такое кеширование существенно ускоряет работу скриптов.

Также Smarty умеет обрабатывать встроенные в шаблоны логические конструкции if-else, преобразуя их в php-код. Аналогично обрабатываются конструкции, названные variable modifiers. Они позволяют убрать некоторые функции из основного скрипта, перенеся их в шаблон и их кешируемые php-скрипты.

{* Написать заголовок заглавными буквами *}

{$title|upper},

Этот текст преобразуется в такой код:

_run_mod_handler("upper", true, $this->_tpl_vars["Name"]); ?> Topic: _run_mod_handler("truncate", true, $this->_tpl_vars["Name"], 40, "..."); ?>

Доступен и набор встроенных переменных таких, как $smarty.now (текущее время). Идилическую картину дополняет вывод окна отладки, содержащего значения переменных, вызов вложенных шаблонов, поддержка настраиваемых фильтров ввода/вывода и плагинов.

Всё было бы прекрасно, будь Smarty меньше в размерах. Сейчас же (версия 2.3.1) "весит" 144 килобайта и на AMD K6 266 MHz работает ощутимо медленно. Разработчики Smarty рекомендуют использовать Zend Accelerator или PHP Accelerator .

DOM - на данный момент последнее слово в шаблонах документов в php. Я описывал модуль в статье «XML: спецификация и функции DOM в PHP».

Несмотря на многословность и большой объём кода, выполняющего достаточно простые операции, DOM XML имеет большие перспективы.

Главный недостаток текстового подхода в редактировании XML-документа (редактирования в скрипте, естественно) - то, что нужно либо внимательно вчитываться в спецификицию XML, либо не быть до конца быть уверенным в том, что же получилось в итоге.

Например, вставить текст в узел - простая задача. Однако в XML-документе служебные символы и символы, не входящие в таблицу ISO, должны быть преобразованы в XML-сущности (<) или в номера символов UTF-8 (&x0442;). В модуле DOM XML достаточно сконвертировать текст в UTF-8 и вызвать метод create_text_node.

На моём сайте пока что работает старый движок, генерирующий текстовую строку, и иногда он выкидывает интересные фокусы с не-well-form-ными документами. Кроме того, объекты можно передавать как параметр функции, а имя вызываемого метода делать переменным.

Наконец, главное преимущество DOM XML - то, что бинарный модуль для текстовой обработки документа в php отсутствует. Это значит, что вам самим придётся писать парсер.

Что касается большого объёма кода, то это вполне естественно. Ведь если вы хотите редактировать документ через текст, то пишете регулярные выражения, используете набор строковых функций. Этого кода нужно тоже немало, если соблюдать условности XML.

Операции с документом через DOM нужно группировать в свои собственные функции, то есть строить DOM-овый класс шаблона.

В отдельный шаблон можно вынести общие для сайта или его разделов данные. Остальное - вставлять в документ приёмом, который я описывал:

document_element(); $child = $root1->child_nodes(); $root2 = $dom2->document_element(); for ($i = 0; $i < sizeof($child); $i++) $root2->append_child($child[$i]->clone_node()); ?>

Для сайта можно сделать простой скрипт, в который будут перенаправляться запросы к документам. В.htaccess пишется следующее:

Options FollowSymLinks RewriteEngine On # проверка наличия файла с тем же именем # и расширением phpxml для корня раздела RewriteCond %{DOCUMENT_ROOT}/$1/index.phpxml -f # если такой файл есть, правило срабатывает RewriteRule ^(+)/?$ /$1/index.php # это правило сработает для адреса, переписанного # по предыдущему правилу, и для всех остальных # файлов, отправляя запрос в скрипт composer.php. RewriteCond %{DOCUMENT_ROOT}/$1.phpxml -f RewriteRule ^(+)\.php$ /composer.php [L]

В скрипте composer.php будет открываться файл с тем же именем, что и запрашивался, но с расширением phpxml. Сервер Apache при обработке правил уже проверил факт существования этого файла.

6.1 Валидация документов

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

С базой было просто: получаешь массив и делаешь из него текстову строку (циклом или классом шаблона наподобие php-templates), либо получить строку при помощи sql2xml дерево объектов (или опять же строку). С файлом работать сложнее, потому что на всякий случай желательно проверять целостность данных.

Есть два подхода в создании разметки. Первый - разметка, ориентированная на данные (data-centric markup), второй - разметка, ориентированная на документ (document-centric markup).

Пример разметки ориентированной на данные:

ETCC FIA-organized racing series. Uses racing cars. BTCC Analogue to ETCC, except that races take. http://btcc.co.uk DTM

Два уровня иерархии - строка + поле (естественно, если их станет 3 или 4, качественно ничего не изменится), в общем, то же самое, что и запрос из базы данных, отформатированный при помощи sql2xml. Пример документо-ориентированной разметки:

FIA organized about 20 racing servies, including 2 touring cars championships. (ETCC) uses significantly tuned road cars, mostly BMW. Another FIA series is (BTCC) is analogue to ETCC, except that races take. Allthough, these are not the world"s most famous championships. DTM (), the most famous Touring racing series not only in Germany.

Этот вариант написан свободным человеческим языком, но данные в элементах acro и title остались те же, их можно получить из документа теми же запросами XPath или XQuery: /championships/championship/title Первый вариант разметки можно представить в виде таблицы базы данных. Можно усложнить его, для примера - фрагмент документа:

DTM Most famous German Touring racing series. Laurent Aiello Bernd Schneider Marcel Fassler Jean Alesi Cristian Albers

От этого документ не перестанет быть data-centric. Новый документ можно представить как 2 таблицы, соединяемые при запросе оператором LEFT JOIN.

Второй документ имеет более сложную структуру, и в общем случае его не получится запихать в таблицу.

Кстати, в этом заключается основное отличие XML-баз данных от не-XML. XML-database работает и с разметкой, ориентированной на документ (а не только в том, что результаты выдаются в XML). Разметку же типа data-centric вполне можно хранить в реляционной БД, а на выходе форматировать утилитой вроде sql2xml .

Так вот, возвращаясь к валидации документов, нужно заметить, что документо-ориентированную разметку очень сложно проверить на соответсвтие DTD или XML-схеме простым строковым парсером.

Ещё пример - разметка формы в моём классе TXF:

0"/>

Я проверяю это через DTD-схему. Проверка соответствия схеме документа - стандартная функция библиотеки DOM XML.

Для общеиспользуемых форматов обмена данными, например, RSS, есть спецификации и DTD-схемы (XML-схемы). Чтобы не забивать голову написанием собственного RSS-парсера, можно просто добавить в документ схему и проверить на допустимость. Затем доставать из документа нужные узлы через get_content или выражения XPath.

6.2 Лирическое отступление

Срочно завершать написание этой части серии меня заставила последняя заметка Spectator-a под названием «Шаблоны в PHP для чайников» .

Призывает забыть слова типа XML, XHTML «и прочий X...», попутно даёт заслуженного пинка Smarty, и, завершая свой ЭКСпромт, призывает умников бриться бритвой Оккама.

Бедная бритва! Подняли на знамёна её, машут ей везде, где можно, тыкают и пытаются нанести ею увечья оппонентам.

К чёрту бритву! К чёрту это дурацкое правило "не плодить сущности сверх необходимого". Это слишком избитая истина, чтобы её напоминать людям, а для того, чтобы оценивать других она вообще не годится. Количество "сверх необходимого" для каждого человека разное. Заказчик сайта может сказать: "А зачем мне ваши скрипты, сделайте в простом HTML, чтобы мы потом FrontPage-ом могли редактировать! Читали про бритву Оккама?"

Я долгое время считал, что основная причина, почему стоит использовать новые технологии в программировании - это эффект масштаба. Как мне написали в комментариях к старой статье, "с ростом объёмов сайта ты утонешь в своих шаблонах". И в своих статьях я упирал именно на это - мол, пожалуйста, балуйтесь со своим хитрым include и кодом, смешанным с HTML, оно поперёк горла встанет, когда надо будет сделать много программного кода.

На самом деле, есть ещё одна причина. Это навыки каждого конкретного человека. Кто хорошо знает XML, XSLT и XPath, либо умеет быстро находить решения задач в этой среде, тот в большем количестве случаев выполнит проект именно на XML-технологиях. Ему это сделать будет просто и легко, потому что он это хорошо умеет. Кто не знает или знает плохо - будет делать "простонародными" способами.

Остаётся лишь вопрос, будут ли его решения на XML-технологиях эффективнее, чем если бы он делал на классах шаблона или смешанном PHP&HTML? Да, будут. Приведу аллегорическое сравнение.

Вы видели, как играют в волейбол опытные игроки и "ламеры"? Команды "кульков" правдами и неправдами перекидывают мяч на другую сторону, чтобы соперник уронил мяч у себя. Нападающий удар они делать не умеют, и, руководствуясь пресловутой бритвой, играют просто. Опытный игрок намного лучше кулька умеет перекидывать мяч. Однако большего результата он добьётся, если выполнит хороший нападающий удар.

Недомыслие — это когда от страсти становится не до мыслей.

Смешные афоризмы

Недомыслие как качество личности – склонность не додумывать последствия своих действий; вести себя недостаточно обдуманно, глупо, неосмысленно; неспособность глубоко и основательно мыслить, правильно понимать что-либо.

Как-то суровой зимой у семьи закончились дрова. Отец вышел на околицу, нашёл мёртвое дерево и срубил его. Весной он увидел, что из пня, срубленного им дерева, пробиваются побеги. - Я был уверен, - сказал отец, - что это дерево мёртвое. Тогда было так холодно, что от мороза его ветви трескались, ломались и падали на землю, как будто у него в корнях не оставалось и капли жизни. Теперь я вижу, что жизнь ещё теплилась в этом стволе.

И, повернувшись к сыну, он сказал: - Запомни этот урок. Никогда не руби дерево зимой. Никогда не принимай решения по недомыслию, в неподходящее время или когда находишься в плохом состоянии души. Жди. Будь терпеливым, плохие времена пройдут. Помни, что весна возвратится.

Недомыслие – дочь глупости и бестолковости. Это отсутствие всякого присутствия здравомыслия. Недомыслие говорит о невнимательности и неуважительности к людям. Кого мы любим и уважаем, о том заботимся, о том беспокоимся и переживаем, поэтому домысливаем все нюансы, все мелочи, которые могут ему навредить или помешать жить. Кого не уважаем и не ценим, к тому проявляем недомыслие.

Недомыслие – союзник идиотства, бестолковости, дурости и безмозглости.

Парень, разыгрывая любознательность, спрашивает у симпатичной стюардессы: - Девушка, а что означает ТУ-154-2Б? – Сам что ли не можешь додуматься? Ну, ТУ - это значит, что самолет выпущен конструктором Туполевым, 150 - количество мест в салоне, а 4 - это сколько членов экипажа. - А 2Б? – Ну, видно недомыслие твой конёк! Это мы с Маринкой.

Недомыслие – это когда человек живёт без понимания, что за каждый поступок придётся отвечать. Ему не приходит в голову мысль, что последствия его действий, как бумеранг, вернутся к нему по закону кармы. И плохое и хорошее обязательно опять вернётся.

Недомыслие – отработанный способ доставить неудобства своему окружению.

В. Щлахтер говорит, что очень часто мы недомыслие воспринимаем за тупость. Или вообще за скотство. Например, водитель выехал на загруженный перекресток. Он перекрыл движение всем, кто стоит на боковой дороге и ждет зеленого сигнала светофора. Но от это сделал, скорее всего, не со злости, и не потому, что он тупая подлая скотина. Он просто не утрудил свою несчастную головушку додумать последствия. Теперь все сигналят ему (чаще ей!), называют самыми нелестными эпитетами из неформальной лексики.

— Оставь коту побольше воды, меня три дня не будет, — сообщает мама. И сынок привозит коту упаковку пластиковых полуторалитровых бутылок. Пей, котяра! То, что коту не под силу открыть бутылку и напиться из нее сыну даже в голову не приходит. Попросили побольше воды — он и принес побольше, какие проблемы? Он это сделал не от тупости. И не от ненависти к несчастному коту. От недомыслия!

Недомыслие приходит в ум гораздо раньше здравомыслия. Оно всегда сопровождается поспешными суждениями.

Учитель всегда предостерегал своих учеников от недомыслия, то есть от поспешных суждений о людях и ещё более от необдуманных советов. Он говорил так: - До тех пор, пока вы не почувствуете сердцем и разумом, что проникли в самую суть проблемы и самые малые сомнения в том, что вы поступаете верно не оставят вас, пусть наилучшим вашим действием будет бездействие, а наивернейшим словом - молчание. В противном случае, ваш совет заставит людей повторить судьбу крестьянина, страдающего от недомыслия.

А что с ним произошло? - спросили ученики. - Его дом, стоящий на возвышении со всех сторон обдувался жестокими ветрами. Крестьянин по недомыслию наивно полагал, что ветер появляется оттого, что окружавшие дом высокие деревья качаются из стороны в сторону. Однажды он осерчал и вырубил все деревья. В результате, лишившийся последней защиты дом стал ещё более холодным и продуваемым ветрами.

Недомыслие – бич людей, думающих только о своих интересах.

Прапорщик спрашивает у солдата: - Что нужно делать при вспышке ядерного взрыва? - Лечь ногами к вспышке и накрыться руками - отвечает тот. - Неправильно. Нужно вытянуть вперед руки с автоматом, чтобы расплавленный металл не капал на казенные сапоги.

Недомыслие толкает человека в среду неопределённости. Когда человек не может домыслить, что будет происходить через несколько минут, значит, он живёт в состоянии полной неопределённости.

Муж вернулся из командировки. Дома никого. Решил спрятаться, чтобы сделать сюрприз жене. Вдруг видит, в квартиру входит жена с каким-то мужчиной. Заходят в спальню. Дверь закрывается, муж скорее к замочной скважине. И видит, как жена целуется с этим мужчиной, он снимает с нее всю одежду, бросаются оба на кровать, он снимает с себя одежду, а трусы бросает в сторону входной двери, где прячется муж, и они, повиснув на ручке, закрывают мужу замочную скважину и весь обзор. И тут муж с досадой думает: — Ну, вот зря день потерял, опять полная неопределенность!

Петр Ковалев

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

Что ж, сама по себе данная тема довольно грузная, и требует определённого времени на анализ и постанувку задачи.

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

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

Все модули представлены ввиде подключаемых к главному документу (индекс-файлу) вставок. Запрос модуля происходит из строки запроса QUERY_STRING, и название подключаемого модуля передаётся в качестве аргумента act. В некотором месте индекса файла происходит изъятие и обработка данного параметра. После, если у пользователя достаточно прав для доступа к модулю в контексте чтения, происходит проверка существования указанного в строке запроса модуля, и если таковой существует, то происходит его подключение к индекс файлу.

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

Для воплощения данного механизма мы будет проверять значение переменной строки запроса `do`, которая обрабатывается в самом модуле и носит информацию о том, к какому разделу модуля необходимо предоставить доступ пользовалю.

Значение do буду фиксированными, данная переменная будет принимать следующие значения:

• main - главная часть модуля (доступно в контексте чтения)
• config - раздел настройки модуля (доступно в контексте записи)
• create - произвести некоторые действия, по добавлению информации в БД (доступно в контексте записи)
• delete - доступ к разделу, предоставляющему возможности удалить некоторую информацию, в контексте данного модуля (доступно в контексте записи)
• edit - доступ к редактированию информации в контексте модуля (доступно в контексте записи)

В целом, этот список можно увеличить, при этом всё зависит лишь только от масштабов проекта и его потребностей в функционале.

Теперь непосредственно о модулях. Кроме физического существования некоторого модуля в контексте файловой системы проекта, модуль так же должен быть добавлен в особую таблицу БД, которая будет содержать информацию о всех существующих модулях в системе. Добавление и изменение данных данной таблицы, обычно, производится непосредственно в контексте модулей, а то есть во время их инсталяции в системе. Однако это уже углубление в принципы посмотроения расширяемых систем, о чём мы как-то в другой раз поговорим, и посему, мы ограничимся ручным обновлением и добавлением данных о модулях.

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

Кроме модулей у нас будут ещё две таблицы, а именно таблица в которой будут хранится данные относительно профилей прав доступа и таблица с информацией о пользователях непосредственно.

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

Что ж, давайте рассмотрим эту особую структуру. Она будет следующей: [ module_indefier: + \: + \;] *

То есть идёт список из пар: имя модуля ":" права чтения "," права записи ";". При этом данная метка обновляется в момент внесения изменений о правах доступа пользователя к системе. Если в системе появляется информация о модуле, который не вошёл в данную метку, то стоит просто произвести процедуру редактирования, и данные сохранятся автоматически.

Теперь же нам осталось рассмотреть структуру всего одной таблицы БД, и мы сможем принятся за реализацию алгоритмической части, а именно таблицы с информацией о пользователях системы, ведь назначение им прав доступа и является нашей главной задачей.

Я не буду добавлять ничего лишнего в неё, но лишь то, что будет использоватся в контексте темы данной статьи. Таблица пользователей будет содержать следующие поля: идентифицатор пользователя (числовой счётчик), логин, пароль (хеш оригинального пароля), профиль безопасности пользователя (идетификатор группы пользователя, относительно прав в системе), и всё. Мне кажется этой информации нам с вами вполне хватит, для реализации поставленной задачи, а уже все остальные надстройки я предоставляю возможность сделать самим.

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

Таблица `modules`:

CREATE TABLE `modules` (`id` bigint(20) NOT NULL auto_increment, `indefier` text collate utf8_unicode_ci NOT NULL, `title` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Таблица `secure_groups`:

CREATE TABLE `secure_groups` (`id` bigint(20) NOT NULL auto_increment, `title` text collate utf8_unicode_ci NOT NULL, `perms` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ;

Таблица `users`

CREATE TABLE `users` (`id` bigint(20) NOT NULL auto_increment, `login` text collate utf8_unicode_ci NOT NULL, `passwd` text collate utf8_unicode_ci NOT NULL, `groupId` int(1) NOT NULL default "0", PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ;

temp=array(); $this->temp["_result"]=0; $this->temp["_uid"]=explode("::",$_COOKIE["site_hash"]); $this->temp["_uid"]=$this->temp["_uid"]; $this->temp["_gid"]=$this->getUserSecurityAccess($this->temp["_uid"]); $this->temp["_conn_id"]=mysql_connect("host","user","passwd"); mysql_select_db("database"); $this->temp["_q1"]=mysql_query("SELECT perms" ."FROM `secure_groups`" ."WHERE id=".$this->temp["_gid"]); $this->temp["_access_stamp"]=mysql_fetch_assoc($this->temp["_q1"]); $this->temp["_access_stamp"]=$this->temp["_access_stamp"]["perms"]; $this->temp["_access_stamp"]=explode(";",$this->temp["_access_stamp"]); $this->temp["_access_stamp"]=array_slice($this->temp["_access_stamp"],0,-1); foreach($this->temp["_access_stamp"] as $this->temp["v"]){ $this->temp["_mod_access"]=explode(":",$this->temp["v"]); $this->temp["_mod_indefier"]=$this->temp["_mod_access"]; if($this->temp["_mod_indefier"]==$module){ $this->temp["_perms"]=explode(",",$this->temp["_mod_access"]); switch($act){ case "r": $this->temp["_result"]=($this->temp["_perms"]==1)? 1:0; break; case "w": $this->temp["_result"]=($this->temp["_perms"]==1)? 1:0; break; } break; } } mysql_close($conn_id); return $this->temp["_result"]; } } ?>

Данный класс внедряет функции, предназначенные для воплещения алгоритмического задания, описанного выше. Сейчас мы обсудим каждую функцию отдельно.

Функция secure::getUserId()

Используя данную функцию, мы подразумеваем, что во время авторизации пользователя в системе в переменной среде $_COOKIE была установлена переменная `site_hash`, состоящая из идентификатора пользователя в системе и хеша для проверки аутентичности его в системе. Функция просто изымает значение идентификатора, возращая его значение на выходе.

Функция secure::getUserSecurityAccess($id)

На выходе данная функция возвращает идентификатор профиля безопасности текущего пользователя в системе.

Функция secure::checkUserPermission($module,$act))

Производится запрос к БД, относительно прав пользователя на произведение действий чтения/записи в контексте переданного в качестве параметра модуля.

Осталось лишь описать процедуру формирования переменной в среде $_COOKIE, и тему статьи можно будет считать расскрытой.

Процедура авторизации будет выглядеть ввиде внесения личных данных пользователя (логин и пароль) в специальную форму, после отправки которой произойдёт обработка данных, переданных пользователем, по-методу функции checkAuthData(), и, в случае корректности данных, будет произведено сохранение данных о пользователе ввиде куки записи на период установленный пользователем, либо в отсутствии заданного значение на период по-умолчанию.

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

Я не привожу форму для отправки, так как это не часть теории программирования, указав лишь идентификаторы полей.

• `ulogin` - логин пользователя
• `upasswd` - пароль пользователя
• `stime` - время сессии, устанавливаемое пользователем (от 1 до 5 часов)
• `auth` - имя кнопки отправки

Вот, в целом и всё. Осталось лишь пробовать, экспериментировать, ошибатся и находить решение, что я всецело и оставляю вам.