Adabas D	Ingres	Oracle (OCI7 и OCI8)
dBase	InterBase	Ovrimos
Empress	FrontBase	PostgreSQL
FilePro (только чтение)	mSQL	Solid
Hyperwave	Direct MS-SQL	Sybase
IBM DB2	MySQL	Velocis
Informix	ODBC	Unix dbm

Кроме того, PHP поддерживает ODBC (Open Database Connection standard), таким образом, разработчики могут работать с любой базой данных, поддерживающей этот всемирно признанный стандарт.

Наконец, средства РНР позволяют программисту работать с внешними компонентами, такими как Enterprise Java Beans или СОМ-объекты Win32. Благодаря этим новым возможностям РНР занимает достойное место среди современных технологий и обеспечивает масштабирование проектов до необходимых пределов.

Вот далеко не полный список основных возможностей и достоинств замечательного языка PHP.

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

Во-первых, хотелось бы отметить, что на сегодняшний день Apache поддерживает функциональность приблизительно девятнадцати миллионов WWW-серверов (по данным Netcraft). Такой несомненный успех провоцирует на внимательный анализ - повторить достижение Apache было бы приятно не только любой группе разработчиков проекта с открытыми исходниками, но и любой коммерческой фирме [30].

Причины успеха Apache можно разделить на две группы: технологические причины, связанные с техническими преимуществами перед конкурентами, и нетехнологические.

Технологическое лидерство. В начальный период своей истории Apache был одним из технологических лидеров на рынке - производительность была достаточно велика, потребности в ресурсах - малы. При этом программа обладала возможностью легкого расширения путем добавления модулей, причем реализованы они были много лучше, чем у конкурентов. Возможность легкого расширения обусловила появление большого количества производных от Apache серверов - Stronghold, Apache/SSL, разнообразных систем создания динамических сайтов (Apache/mod_perl, PHP и др.), удовлетворяющих большинство потребностей Web-разработчиков по сегодняшний день [18].

Технологический консерватизм. Авторы популярных программ быстро оказываются заваленными пожеланиями пользователей. Если им следовать, то программы перегружаются функциональностью, нужной только малому числу клиентов, а сложность кода растет одновременно с числом проблем. Авторам Apache удалось сохранить необходимый баланс в этой области, разрабатываемое ими ПО имеет репутацию стабильного и предсказуемого [30].

Открытость процесса разработки. Процесс разработки Apache открыт для наблюдения и комментирования всем желающим и потому предсказуем. Это позволяет выпускать дополнительные модули к новым версиям практически одновременно с их выходом [18].

«Демократическая» разработка. В проекте Apache реализована уникальная схема разработки - по каждому изменению проводится голосование, причем «существенные» изменения могут быть остановлены правом вето любого члена группы разработчиков, а несущественные - должны набрать больше голосов «за», чем «против». Такая схема позволяет блокировать сомнительные технологические решения, поддерживая технологический консерватизм.

Поддержка пользователей. Несмотря на огромную пользовательскую базу и некоммерческий статус, поддержка Apache была и остается очень хорошей по качеству - сообщения о проблемах анализируются в течение одного-двух дней [18].

Лицензирование. Существенной причиной успеха Apache является действительно свободное лицензирование. Apache License, в отличие от наиболее распространенной в среде ПО с открытыми исходниками лицензии GNU GPL, не навязывает свободное распространение производных работ, а требует лишь сохранения права на имя - указания, что производный проект использует код, разработанный Apache Group. При такой схеме лицензирования коммерческие компании охотнее вкладывают свои ресурсы в развитие продукта, примером может служить участие IBM в разработке Apache 2.0 и перенос Apache на платформу Windows [18].

Все перечисленные причины успеха Apache являются существенными, отсутствие любой из них заметно ухудшило бы продукт в глазах части либо всех пользователей. Ниже представлена таблица сравнения Apache с двумя другими наиболее популярными среди вэб-разработчиков серверами Microsoft IIS и Lotus Domino по основным критериям ПО для серверов:

Критерий	Вес критерия	Apache	Microsoft IIS	Lotus Domino
Цена	40	+	-	-
Производительность	20	+	+	+
Модульность	25	+	-	-
Открытые исходные коды	15	+	-	-
Итого	100	100	20	20

Таблица говорит сама за себя - Apache на сегодняшний день является лидирующим в мире ПО для вэб-серверов, так например по данным Интернет-проекта Netstat, только в России «доля рынка» Apache составляет около 80%, согласитесь - довольно внушительная цифра [30].

Ну и наконец, перейдём к выбору СУБД для тестового портала. Поскольку был выбран язык PHP и сервер Apache, то СУБД следует выбирать исходя из двух предыдущих компонентов. На сегодняшний день существует множество СУБД для вэб-разработок и не только для них. Среди наиболее популярных из них такие системы как Oracle, MSSQL, Postgres, Interbase/FireBird, MySQL. Все эти системы в той или иной степени ориентированы для вэб-разработок, хотя, например, Oracle и Interbase/FireBird изначально не были ориентированы для вэб-среды. В принципе любая из этих СУБД подойдёт для создания вэб-систем. Однако, следует выбрать самую подходящую и более адаптированную для Интернет-разработок. Все из выше перечисленных СУБД поддерживаются PHP, но для совместного функционирования некоторых из низ нужны соответствующие расширения - библиотеки для языка PHP. Начиная с версии 4.0 в РНР автоматически поддерживается СУБД MySQL, что является одним из факторов обусловленности выбора данной СУБД для поставленной задачи.

MySQL представляет собой очень популярную систему управления базами данных с открытыми исходными текстами, разрабатываемую MySQL AB. MySQL AB является коммерческой компанией, строящей свой бизнес на сервисах, сосредоточенных на базе данных MySQL [19].

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

Чтение 2000000 строк по индексу	Время (сек.)
MySQL	367
DB2_odbc	1206
Informix_odbc	121126
MS-SQL_odbc	1634
Solid_odbc	877
Sybase_odbc	17614
Вставка 350768 строк	Время (сек.)
MySQL	381
DB2_odbc	3460
Informix_odbc	2692
MS-SQL_odbc	4012
Solid_odbc	1801
Sybase_odbc	4802

Обратите внимание, что Oracle - одна из мощнейших СУБД - не включена в тест потому, что компания-разработчик потребовала удалить эти данные. Причины такого отношения к независимым измерениям производительности могут быть вызваны лишь откровенным завышением характеристик сервера компанией Oracle [29].

Следующим поистине важным преимуществом является то, что MySQL поддерживает огромные объемы данных. Известен случай использования MySQL на 60000 таблиц, хранящих около 5000000000 строк! Последние версии этой СУБД не имеют собственных ограничений на размер таблиц, и всё зависит лишь от операционной системы, в то время как остальные СУБД хотя и позволяют обрабатывать таблицы огромных размеров(несколько гигабайт), но всё ещё имеют таковые ограничения [29].

Система имеет интерфейсы для языков C, C++, Eiffel, Java, Perl, PHP, Python и Tcl. Что делает её доступной для разработчиков пишущих свои программы на данных языках. Кроме того, MySQL имеет встроенную систему защиты информации - привилегии и система паролей, которая является очень гибкой и безопасной, и позволяет проверку, основанную на имени хоста. Пароли безопасны потому, что вся передача пароля шифрована, когда происходит соединение с сервером [20].

Все эти факты побудили остановить выбор именно на этой СУБД. К тому же для данной связки (PHP-Apache-MySQL) существуют готовые инсталляторы-триады в одном файле, т.е. такой инсталлятор устанавливает все три компонента сразу, а также производит соответствующие настройки для корректной и взаимосвязанной работы всех трёх компонентов, чего не существует для других вариантов решения в данной области. Ну и наконец, немаловажным фактором выбора именно этих компонентов является то, что все они бесплатны.

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

РНР - версия 5.0.0

Apache - версия 1.3.31

MySQL - версия 5.0

4.2 Структура тестового портала

Структура тестового портала состоит из следующих основных частей:

· база данных портала

· программное ядро

Рассмотрим подробно каждую часть.

База данных портала

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

· курсы (kurs)

· пользователи (users)

· доступ (dostup)

· лимиты на пересдачу (limits)

· лимиты на количество вопросов (ctrl_counts)

· вопросы (questions)

· студенты (students)

· результаты (results)

Таблица «Курсы». Эта таблица будет содержать в себе информацию о курсах портала. В таблице 1 приведена структура этой таблицы:

№	Название поля	Тип поля	Описание
1	kurs_ID	Счётчик	Числовой идентификатор курса (первичный ключ)
2	name	Текстовый	Название курса
3	Ped	Текстовый	Ф.И.О тьютора
4	Act	Логический	Активность курса
5	Dat	Дата/Время	Дата последнего редактирования

Поле «kurs_id» является первичным ключом таблицы «Курсы» и является связующим полем с другими таблицами. Это поле имеет тип «Счётчик» - это означает, что при вставке новой записи, поле примет очередное значение виртуального счётчика, который просто инкрементирует своё значение на единицу.

Хотелось бы обратить внимание на поле «ACT» - с помощью этого поля регулируется активность того или иного курса. По умолчанию курс всегда активен, принимает значение True в поле «Act». Что понимается под активностью курса? Всё просто: если курс активен, то студенты имеют право доступа к курсу, в противном случае - нет. Для чего это нужно? Допустим, было обнаружено что в том или ином курсе при вводе вопросов был допущен ряд существенных ошибок (вопросы слишком лёгкие, неверные ответы, повтор вопросов, и т.п.), тогда во избежание недоразумений администратору портала будет достаточно всего лишь привести курс в неактивное состояние до устранения ошибок.

Таблица «Пользователи». Данная таблица содержит информацию о пользователях тестового портала, т.е. о людях имеющих непосредственный доступ к порталу. Сюда в первую очередь относится администратор, а затем операторы. В таблице 2 приведена структура этой таблицы:

№	Название поля	Тип поля	Описание
1	us_ID	Счётчик	Числовой идентификатор пользователя (первичный ключ)
2	Fio	Текстовый	Ф.И.О. пользователя
3	Mail	Текстовый	Адрес электронной почты пользователя
4	Login	Текстовый	Логин пользователя
5	Pass	Текстовый	Пароль пользователя
6	Status	Множество	Статус пользователя
7	Dat	Дата/Время	Дата последнего редактирования

С полями данной таблицы всё предельно ясно, названия полей говорят сами за себя. Разве что поле «Status» требует некоторого пояснения. Это поле принимает одно из следующих: либо `O', либо `A', т.е. либо оператор, либо администратор соответственно. По сути это поле в данном случае можно было заменить на логическое, но прелесть множества в том, что сюда можно добавить ещё десятки значений, тем самым при расширении и апгрейде тестового портала не будет проблем с добавлением новых категорий пользователей.

Поле «Pass» хранит в себе пароли пользователей в зашифрованном виде, что повышает безопасность портала. Осуществление шифрации происходит на уровне СУБД MySQL с помощью встроенной функции SHA1, которая шифрует текстовую информацию одноимённым криптографическим алгоритмом. Конечно можно было бы использовать внешнюю шифрацию или собственный алгоритм, но лучше будет отдать предпочтение уже зарекомендовавшему себя алгоритму, к тому же взлом шифра данного алгоритма очень и очень не прост.

Таблица «Доступ». В этой таблице будет располагаться информация о доступе пользователей(операторов) к тем или иным курсам. Естественно это касается только операторов, т.к. администратор имеет полный доступ ко всей информации портала. В таблице 3 приведена структура этой таблицы:

№	Название поля	Тип поля	Описание
1	us_ID	Счётчик	Числовой идентификатор пользователя (внешний ключ)
2	kurs_ID	Счётчик	Числовой идентификатор курса (внешний ключ)
3	Sel	Логический	Разрешение на чтение
4	Edit	Логический	Разрешение на редактирование
5	Ins	Логический	Разрешение на вставку
6	Del	Логический	Разрешение на удаление
7	Lim	Логический	Разрешение на изменение лимитов на пересдачи
8	Dat	Дата/Время	Дата последнего редактирования

Поля представляющие из себя внешние ключи (us_ID, kurs_ID) могут содержать в себе только значения из определённых полей соответствующих таблиц. В данном случае поле «us_ID» содержит в себе значения поля «us_ID» таблицы «Пользователи», а поле «kurs_ID» - значения поля «kurs_ID» таблицы «Курсы». Таким образом если попытаться вставить в поле «kurs_ID» значение, которого не существует в одноимённом поле таблицы «Курсы» мы получим ошибку о несоответствии внешнего ключа и вставка (изменение) будет отменено, т.е. проблема несоответствия данных при использовании внешних ключей решается на уровне СУБД.

Поля sel, edit, ins и del хранят в себе разрешение на чтение, редактирование, вставку и удаление вопросов того или иного курса, и назначают доступ оператору в соответствии с его идентификатором. Поле lim даёт либо запрещает оператору возможность редактирования лимитов на пересдачу контролей (подробнее о контролях смотрите ниже).

Таблица «Лимиты на пересдачу». Данная таблица хранит информацию о лимитах (ограничениях) на пересдачу контролей, т.е. имеется возможность ограничить количество пересдач того или иного контроля. В том случае, когда студент достиг лимита на пересдачу данного контроля (например, лимит контроля равен 3 - студент пересдавал 3 раза), последующая пересдача будет недоступна. Таким образом у обучающихся будет стимул для более глубокого и лучшего усвоения материала выбранного курса. В таблице 4 приведена структура этой таблицы:

№	Название поля	Тип поля	Описание
1	kurs_ID	Счётчик	Числовой идентификатор курса (внешний ключ)
2	Tek1	Числовой	Пересдачи 1 текущего контроля
3	Tek2	Числовой	Пересдачи 2 текущего контроля
4	Tek3	Числовой	Пересдачи 3 текущего контроля
5	Tek4	Числовой	Пересдачи 4 текущего контроля
6	Prm1	Числовой	Пересдачи 1 промежуточного контроля
7	Prm2	Числовой	Пересдачи 2 промежуточного контроля
8	Itg	Числовой	Пересдачи итогового контроля
9	Dat	Дата/Время	Дата последнего редактирования

Почему выбрана именно такая система контроля? Конечно можно было сделать портал основанный на лекционных контролях, т.е. после каждой лекции соответствующий контроль. Но так как в данном случае мы имеем дело только с тестовым порталом, не содержащим внутри себя непосредственно лекций, то лучшим вариантом будет именно выбранный вариант. К тому же такая система контроля знаний (разделённая на текущие, промежуточные и итоговый контроли) соответствует положениям о Высшем образовании Республики Узбекистан и используется во всех ВУЗах Узбекистана.

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

Таблица «Лимиты на количество вопросов». Данная таблица хранит информацию о лимитах (ограничениях) на количество вопросов того или иного контроля при прохождении его студентами. В таблице 5 приведена структура этой таблицы:

№	Название поля	Тип поля	Описание
1	kurs_ID	Счётчик	Числовой идентификатор курса (внешний ключ)
2	Tek1	Числовой	Количество вопросов 1 текущего контроля
3	Tek2	Числовой	Количество вопросов 2 текущего контроля
4	Tek3	Числовой	Количество вопросов 3 текущего контроля
5	Tek4	Числовой	Количество вопросов 4 текущего контроля
6	Prm1	Числовой	Количество вопросов 1 промежуточного контроля
7	Prm2	Числовой	Количество вопросов 2 промежуточного контроля
8	Itg	Числовой	Количество вопросов итогового контроля
9	Dat	Дата/Время	Дата последнего редактирования

Например, если проставить в поле «Тек1» того или иного курса «5», то при прохождении первого текущего контроля студент должен будет ответить на пять вопросов.

Таблица «Вопросы». В этой таблице будут храниться вопросы всех курсов и контролей портала. В таблице 6 приведена структура этой таблицы:

№	Название поля	Тип поля	Описание
1	q_ID	Счётчик	Числовой идентификатор вопроса (первичный ключ)
2	kurs_ID	Счётчик	Числовой идентификатор курса (внешний ключ)
3	Text	Текстовый	Текст вопроса
4	A_	Текстовый	Ответ А
5	B_	Текстовый	Ответ В
6	C_	Текстовый	Ответ С
7	D_	Текстовый	Ответ D
8	Ans	Множество	Правильный ответ (a,b,c, или d)
9	Typ_ctrl	Множество	Тип контроля (1 текущий,2 текущий,…, итоговый)
10	Dat	Дата/Время	Дата последнего редактирования

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

Каждый вопрос имеет по четыре варианта ответов, а также поле «Ans», где указан буквенный идентификатор правильного ответа.

Таблица «Студенты». Данная таблица будет хранить информацию о зарегистрированных в системе студентах. В таблице 7 приведена структура этой таблицы:

№	Название поля	Тип поля	Описание
1	stud_ID	Счётчик	Числовой идентификатор студента (первичный ключ)
2	Fio	Текстовый	Ф.И.О. студента
3	Gr	Дата	Дата рождения студента
4	Mail	Текстовый	Адрес электронной почты студента
5	Login	Текстовый	Логин студента
6	Pass	Текстовый	Пароль студента
7	Dat	Дата/Время	Дата последнего редактирования

Видно, что эта таблица по своей структуре почти идентична таблице «Пользователи», за исключением того что эти таблицы несут в себе совсем разные смысловые нагрузки.

Таблица «Результаты». В таблице будет храниться информация о результатах сдачи контролей студентами по тем или иным курсам. По сути таблица «Результаты» будет электронной зачётной книжкой студентов. В таблице 8 приведена структура этой таблицы:



№	Название поля	Тип поля	Описание
1	Kurs_ID	Счётчик	Числовой идентификатор курса (внешний ключ)
2	stud_ID	Счётчик	Числовой идентификатор студента (внешний ключ)
3	Tek1_bal	Числовой	Набранный балл за 1 текущий контроль
4	Tek1_cnt	Числовой	Количество пересдач 1 текущего контроля
5	Tek1_dat	Дата/Время	Дата/время последней сдачи (пересдачи) 1 текущего контроля
6	Tek2_bal	Числовой	Набранный балл за 2 текущий контроль
7	Tek2_cnt	Числовой	Количество пересдач 2 текущего контроля
8	Tek2_dat	Дата/Время	Дата/время последней сдачи (пересдачи) 2 текущего контроля
9	Tek3_bal	Числовой	Набранный балл за 3 текущий контроль
10	Tek3_cnt	Числовой	Количество пересдач 3 текущего контроля
11	Tek3_dat	Дата/Время	Дата/время последней сдачи (пересдачи) 3 текущего контроля
12	Tek4_bal	Числовой	Набранный балл за 4 текущий контроль
13	Tek4_cnt	Числовой	Количество пересдач 4 текущего контроля
14	Tek4_dat	Дата/Время	Дата/время последней сдачи (пересдачи) 4 текущего контроля
15	Prm1_bal	Числовой	Набранный балл за 1 промежуточный контроль
16	Prm1_cnt	Числовой	Количество пересдач 1 промежуточного контроля
17	Prm1_dat	Дата/Время	Дата/время последней сдачи (пересдачи) 1 промежуточного контроля
18	Prm2_bal	Числовой	Набранный балл за 2 промежуточный контроль
19	Prm2_cnt	Числовой	Количество пересдач 2 промежуточного контроля
20	Prm2_dat	Дата/Время	Дата/время последней сдачи (пересдачи) 2 промежуточного контроля
21	Itg_bal	Числовой	Набранный балл за итоговый контроль
22	Itg_cnt	Числовой	Количество пересдач итогового контроля
23	Itg_dat	Дата/Время	Дата/время последней сдачи (пересдачи) итогового контроля

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

До сего момента каждая таблица была рассмотрена как отдельное целое, на рисунке 4.2.1 представлена схема связи всех таблиц:



Из рисунка явно видно связь всех таблиц между собой. О самом же процессе функционирования тестового портала и практическом применении данной БД в нём рассказывается ниже в разделе «Программное ядро».

Программное ядро

Программное ядро тестового портала в свою очередь делится на 3 блока

- администраторский

- операторский

- студенческий

Программное ядро состоит из следующих папок, которые находятся в главном каталоге TEST_PORTAL, расположенном в корневом вэб-каталоге Apache-сервера(htdocs):

1) SQL. Содержит единственный файл - testportal_create.sql - который нужен для создания первичной(пустой) базы данных портала

2) ADM. Содержит в себе скриптовые файлы необходимые для работы администратора

3) OPER. Содержит в себе скриптовые файлы необходимые для работы операторов

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

5) Студенческая часть находится в самом каталоге TEST_PORTAL

Рассмотрим каждую часть в отдельности подробнее.

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

Название файла	Краткое описание
admin.php	Главный файл, обеспечивающий интерфейс администратора
adm_ch_data.php	Изменение персональных данных администратора
adm_ch_pass.php	Изменение пароля администратора
adm_logout.php	Обеспечение выхода администратора из системы
ch_acces.php	Редактирование доступа к курсу
ch_acces_by_us.php	Редактирование доступа к курсам относительно пользователя
ch_ctrl_count.php	Редактирование лимитов на количество вопросов контролей
ch_kurs.php	Редактирование информации о курсах
ch_limit.php	Редактирование лимитов на пересдачу
ch_quest.php	Редактирование вопросов
ch_user.php	Редактирование пользовательских данных
del_kurs.php	Удаление курсов
del_quest.php	Удаление вопросов
del_stud.php	Удаление студентов
del_user.php	Удаление пользователей
new_kurs.php	Добавление курсов
new_quest.php	Добавление вопросов
new_user.php	Добавление пользователей
output_fns.php	Файл, отвечающий за визуальное оформление админ-интерфейса
search_KURS.php	Поиск курсов
search_quest.php	Поиск вопросов
search_stud.php	Поиск студентов
search_user.php	Поиск пользователей
testportal_fns.php	Инклюд-файл, подключающий другие необходимые файлы
user_fns.php	Функции для работы с БД

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

if (isset($_POST['user']) && isset($_POST['password']))

{

$user = $_POST['user'];

$pass = $_POST['password'];

if ($user && $pass)

{

try

{

log_adm($user,$pass);

$_SESSION['valid_adm'] = $user;

$title = 'Тест-ПОРТАЛ :: Добро пожаловать в админ-модуль!';

$res = get_adm_data();

$msg = '<font face="Verdana" size="2">Добро пожаловать в систему </font><font face="Verdana" size="2" color="#FFFFFF">'

.$res['fio']."!</font>";

}

catch (Exception $e)

{

show_main('Тест-ПОРТАЛ :: Авторизация','Вы не вошли в систему! Авторизуйтесь!',$typ);

exit;

}

}

Скрипт проверяет состояние POST-переменных user и password, и если они установлены, то передаёт их функции log_adm, в которой и происходит проверка корректности данных.

Функция log_adm по полученным данным возвращает либо True (удачная авторизация), либо генерирует исключительную ошибку, которую в свою очередь отлавливает вышеизложенный оператор TRY. Если оператор TRY поймал ошибку, то он сразу же переходит к блоку catch, и заново выводит форму авторизации, в противном случае устанавливается сессионная переменная VALID_ADM, которая будет хранить в себе в течении всей сессии логин администратора. Эта сессионная переменная нужна для того, чтобы администратор (пользователь) не вводил бы каждый раз логин/пароль при переходе на ту или иную ссылку. Достаточно установить такую переменную один раз при удачной авторизации и она будет передаваться в другие скрипты на проверку, таким образом пользователь будет избавлен от бесконечных авторизаций, а также будет снижена нагрузка на СУБД. Данный подход практикуется во многих современных Интернет-приложениях и является относительно быстрым и безопасным. После установки этой переменной пользователю открывается окно администраторского интерфейса, где доступны следующие функции: просмотр и смена персональных данных и пароля администратора; поиск, добавление, удаление и редактирование курсов, пользователей, вопросов, студентов.

Очень важной функцией, требующей обеспечения особой безопасности является смена пароля администратора. Эту функцию обеспечивает файл adm_ch_pass.php. Данный файл принимает три пост-переменные: текущий пароль, новый пароль и подтверждение нового пароля. Далее проверяется не пусты ли эти переменные, т.е. заполнил ли все поля пользователь, и если хотя бы одно из них не заполнено, то выдаётся сообщение о недостаточности данных. Также проверяется соответствие нового пароля и его подтверждение, если они не идентичны, то также выдаётся соответствующее сообщение об ошибке. Если же все условия удовлетворены, то переменные передаются функции adm_ch_pass(файл user_fns.php) и происходит попытка изменения пароля администратора. Причём надо отметить, что данная функция невольно производит вторичную попытку проверки валидности логина и текущего пароля администратора в следующем SQL-запросе:

«update users set pass=sha1('$new_pass') where status='A' and pass=sha1('$old_pass') and login='$user'»

т.е. смена пароля происходит у того пользователя, который имеет статус «A» (администратор), пароль идентичный текущему введённому паролю и логин равный переданному, в нашем случае логину, который хранится в сессионной переменной VALID_ADM.

Тут же рождается вопрос: «А что будет если с совершенно другой вэб-страницы передать эти три переменные, что пароль администратора поменяется?» Разумеется нет, так как в этом файле прежде, чем вообще производить какие-либо действия сначала проверяется вошёл ли администратор в систему, если это не так то скрипт ничего не будет делать и отобразит просто белый экран. Эта задача возложена на функцию check_adm (user_fns.php), которая включена во все скриптовые файлы администраторского блока:

function check_adm()

{

global $valid_adm;

if (isset($_SESSION['valid_adm']))

{

return true;

}

}

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

Как было сказано выше - реализация визуальной части администраторского блока возложена на скрипт output_fns.php. По сути данный файл на 70% состоит из простого HTML-кода, но именно оставшиеся 30% PHP-кода отвечают за то, что и как будет отображаться. Хотелось бы обратить внимание на наиболее интересные и сложные части данного скрипта. Основной и часто используемый инструмент отображения - это постраничный вывод информации из базы данных. Так как объём выводимой информации может достигать довольно-таки внушительных размеров, то не целесообразно было бы отображать сразу всю запрашиваемую информацию, гораздо более эффективно, удобнее и быстрее отображать информацию постранично - информация делится на страницы по n-записей на каждой, на каждой странице отображается очередная порция данных. Данный подход может показаться на первый взгляд сложным и непонятным, но при правильно выбранном алгоритме реализовать его достаточно просто. Рассмотрим например, функцию выводящую вопросы того или иного курса get_quest (output_fns.php), остальные функции обеспечивающие постраничный вывод практически идентичны этой функции.

function get_quest()

{

$num_q = 15;

$id = $_GET['id'];

$page = $_GET['page'];

$name = get_kurs_info($id)->fetch_assoc();

$name = $name['name'];

$res_q = get_kurs_quest($id,'0');

$cnt_q = $res_q->num_rows;

$total = intval(($cnt_q - 1) / $num_q) + 1;

$page = intval($page);

if(empty($page) || $page < 0) $page = 1;

if($page > $total) $page = $total;

$start = $page * $num_q - $num_q;

$result = get_kurs_quest_by_page($id,$start,$num_q);

if($result->num_rows > 0)

{

echo '<b>Текущий курс:</b><font face="Verdana" size="2"> '.$name.'</font><p>';

echo '<input type="hidden" name="page" value="'.$page.'">';

echo '<table border="1" width="580" cellpadding="0" cellspacing="0"><tr><td height="30" bgcolor="#333339"><font face="Verdana" size="2" color="white">'.

'Вопросы курса (Cтраниц: '.$total.' :: Вопросов: '.$cnt_q.' :: Страница №: '.$page.')</td></tr>';

for($i = 0; $i < $result->num_rows; $i++)

{

$row = $result->fetch_assoc();

echo '<tr><td><table bgcolor="white"><tr><td width="580">'.htmlspecialchars($row['text']).'</td></tr></td></tr>';

echo '<tr><td align="right"><a target="_blank" href="admin.php?typ=quest_info&id='.$row['q_id'].

'&page='.$page.'"><font face="Verdana" size="2">Подробно</a>&nbsp;&nbsp;<a href="del_quest.php?id='.

$row['q_id'].'"><font color="red" face="Verdana" size="2">Удалить</td></tr></table>';

}

echo '</table>';

if ($page != 1 && $page-1 != 1) $pervpage = '<a href=admin.php?typ=get_quest&id='.$id.'&page=1>Первая</a> |

<a href=admin.php?typ=get_quest&id='.$id.'&page='. ($page - 1) .'>Предыдущая</a> |';

if ($page != $total && $page+1 != $total) $nextpage = ' | <a href=admin.php?typ=get_quest&id='.$id.'&page='. ($page + 1) .'>Следующая</a> | <a href=admin.php?typ=get_quest&id='.$id.'&page=' .$total. '>Последняя</a>';

if($page - 2 > 0) $page2left = ' <a href=admin.php?typ=get_quest&id='.$id.'&page='. ($page - 2) .'>'. ($page - 2) .'</a> | ';

if($page - 1 > 0) $page1left = '<a href=admin.php?typ=get_quest&id='.$id.'&page='. ($page - 1) .'>'. ($page - 1) .'</a> | ';

if($page + 2 <= $total) $page2right = ' | <a href=admin.php?typ=get_quest&id='.$id.'&page='. ($page + 2) .'>'. ($page + 2) .'</a>';

if($page + 1 <= $total) $page1right = ' | <a href=admin.php?typ=get_quest&id='.$id.'&page='. ($page + 1) .'>'. ($page + 1) .'</a>';

echo $pervpage.$page2left.$page1left.'<b>'.$page.'</b>'.$page1right.$page2right.$nextpage;

}

else

{

echo 'Вопросов по курсу не найдено!';

}

}

Рассмотрим эту функцию построчно. Переменная $num_q принимает количество вопросов, которое требуется отображать на каждой странице, в данном случае - 15. В принципе это число можно изменять на другое приемлемое. Далее принимается идентификатор курса и страницы, которую нужно отобразить. После чего согласно идентификатора курса функция get_kurs_quest возвращает количество всех вопросов курса в переменную $cnt_q. Используя эту переменную с помощью строки

$total = intval(($cnt_q - 1) / $num_q) + 1;

мы уже узнаём сколько всего страниц потребуется отобразить. Здесь просто общее количество вопросов делится на количество вопросов необходимое для отображения, причём функция intval даёт возможность всегда получать только целую часть полученного числа, мы используем её здесь потому что в некоторых случаях результат ($cnt_q - 1) / $num_q может оказаться вещественным. Точно также мы вырезаем из переданного идентификатора страницы $page вещественную часть, т.к. скрипту может быть умышленно передан вещественный идентификатор и без должной обработки вывод будет вызывать ошибку. Далее идентификатор страницы проверяется на пустое и отрицательное значение, если это произошло, то идентификатор страницы автоматически сбрасывается ну нуль. Точно также проверяется не превышает ли идентификатор максимальное число страниц ($total), если так, то идентификатор страницы сбрасывается на значение последней страницы. Затем вычсляем начиная с какой записи следует выводить вопросы:

$start = $page * $num_q - $num_q;

Функция get_kurs_quest_by_page(user_fns.php) возвращает «порцию» вопросов в соответствии с переданными ей параметрами (ограничениями). Основная строка этой функции

$result = $conn->query("select * from questions where kurs_id='$id' LIMIT $start, $num");

возвращает набор данных из таблицы «questions»(вопросы) состоящий из $num записей, начиная с записи $start. Затем если количество строк больше нуля, т.е. имеется очередная порция данных, то происходит табличный вывод вопросов, в противном случае выдаётся сообщение об ошибке. Ну и наконец, потребуется вывод списка оставшихся страниц, если таковые имеются. Например, данная строка проверяет если страница не является первой и её значение уменьшенное на один также не является равным одному, то значит нужно вывести ссылку на предыдущую и первую страницы

if ($page != 1 && $page-1 != 1) $pervpage = '<a href=admin.php?typ=get_quest&id='.$id.'&page=1>Первая</a> |

<a href=admin.php?typ=get_quest&id='.$id.'&page='. ($page - 1) .'>Предыдущая</a> |';

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

Первая | Предыдущая | 3 | 4 | 5 | Следующая | Последняя

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

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

Как известно поиск является неотъемлемой частью вэб-систем имеющих дело с БД, каковой является наш тестовый портал. В частности администратору предоставляется возможность поиска пользователей, вопросов, курсов и студентов по различным параметрам. Весь процесс поиска в основном ложится на SQL-запросы функций файла user_fns.php. Рассмотрим например, поиск пользователей.

Поиск пользователей, так же как и другой информации, можно произвести по одному или нескольким параметрам. Поиск пользователей можно произвести по Ф.И.О., адресу электронной почты и логину, либо вариации вышеупомянутых параметров. Введённые данные передаются скрипту search_user.php, который в свою очередь проверяет - есть ли хотя бы один переданный параметр и в случае успеха передаёт параметр(ы) в функцию user_search. Эта функция по переданным ей параметрам возвращает набор данных. Например, если переданы все три параметра (Ф.И.О., адрес электронной почты, логин), то запрос этой функции выглядит следующим образом:

$quer="select * from users where fio like '%$fio%' and mail like '%$mail%' and login

like '%$log%' and status<>'A'";

Данный запрос включает в себя SQL-функцию LIKE, которая возвращает данные из БД согласно строкового параметра. Например, фрагмент «fio like '%ИВАНo%'» означает, что запрос вернёт данные, в которых значения поля FIO содержат в себе набор букв «ИВАН», причём неважно - в конце, середине или начале данных. Если поставить знак «%» только вначале параметра, то условие бы звучало примерно так: «вернуть все записи, в которых значения поля FIО имеют в конце набор букв `ИВАН'». В нашем же случае в результирующий набор данных могут попасть данные вида:

ИВАНов

лиВаНов

дИВАНов

ИВАН

Как видим, довольно-таки удобная функция позволяющая проводить поиск на частичное совпадение, что немаловажно при больших и похожих друг на друга данных. Причём как можно заметить, функция не разборчива к регистру букв, т.е. при поиске значение «ИвАН» будет равносильно «ИВАН» и т.п. Разумеется поиск можно было бы проводить на точное совпадение, убрав функцию LIKE, но где например, гарантия того, что администратор (пользователь) не ошибётся в одном-двух символах при вводе очередной информации?

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

Наконец, рассмотрим как происходит выход из системы. За выход администратора из системы отвечает скрипт adm_logout.php. Данный файл подключается к текущей сессии и извлекает из неё сессионную переменную valid_adm, после чего стирает её из сессии:

unset($_SESSION['valid_adm']);

а затем полностью «убивает» всю сессию:

$resul_dest = session_destroy();

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

Итак в данном подразделе были рассмотрены основные моменты программной части администраторского блока, перейдем теперь к рассмотрению операторского блока.

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

Название файла	Краткое описание
oper.php	Главный файл, обеспечивающий интерфейс оператора
ch_data.php	Изменение персональных данных оператора
ch_pass.php	Изменение пароля оператора
logout.php	Обеспечение выхода оператора из системы
ch_limit.php	Редактирование лимитов на пересдачу
ch_quest.php	Редактирование вопросов
del_quest.php	Удаление вопросов
new_quest.php	Добавление вопросов
Output.php	Файл, отвечающий за визуальное оформление оператор-интерфейса
Oper_fns.php	Функции для работы с БД
Oper_inc.php	Инклюд-файл, подключающий другие необходимые файлы

Индекс-файлом операторского блока является файл - oper.php. Интерфейс оператора строится на основе его доступа, т.е. оператору будут доступны только те функции доступ к которым ему разрешён. Первоначальное меню одинаково для всех операторов и состоит из следующих пунктов: персональные данные, смена пароля, доступ и выход. Все меню практически идентичны с одноименными меню администратора за исключением меню «Доступ» - именно через него оператор ведёт всю работу.

После авторизации оператора как и в случае с администратором устанавливается сессионная переменная valid_oper содержащая в себе логин авторизованного оператора, но помимо логина устанавливается переменная valid_oper_id, которая хранит в течении сессии идентификатор авторизованного оператора. Идентификатор оператора нужен для проверок доступа оператора, т.к. всё что связано с доступом реализуется через идентификаторы операторов из принципов минимизации БД.

Итак, меню «Доступ». Это меню постранично показывает список тех курсов, к которым оператор имеет хотя бы минимальный доступ (доступ на чтение). Эта задача реализуется функцией show_enabled_kurses (output.php). Главной строчко здесь является строка

$result=get_kurs_by_page($oper_id,$start,$num_k,true);

В переменную $result возвращается список доступных оператору курсов с помощью функции get_kurs_by_page. Этой функции передаётся идентификатор оператора, затем производится запрос следующего вида:

"select * from kurs,dostup where dostup.kurs_id=kurs.kurs_ID and dostup.us_ID=$us_id and sel='1'"

Данный запрос по идентификатору оператора сверяет его доступ ко всем курсам и возвращает только те курсы, к которым оператор имеет доступ хотя бы на чтение (sel='1'). Далее функция show_enabled_kurses проверяет, есть ли хотя бы одна строка в результирующем наборе данных (имеются доступные курсы):

if($result->num_rows > 0)

если это так, то отображается таблица доступных курсов, в противном случае выдаётся сообщение о том, что оператор не имеет доступ ни к одному из курсов.

По нажатию уже на конкретный курс будет отображён интерфейс работы с данным курсом. Опять таки здесь всё зависит от степени доступа оператора. По умолчанию у оператора при работе с конкретным курсом имеется минимальный набор информации: информация о курсе (наименование, тьютор), количество вопросов курса, информация о лимитах курса и список вопросов курса. Здесь всё понятно, гораздо более интересно рассмотреть ситуацию когда оператор имеет доступ более чем только на чтение. Начнём с лимитов курса. При выводе лимитов курса, происходит проверка доступа оператора к лимитам - функция show_kurs_access(output.php). Сначала мы вторично проверяем доступ оператора к курсу:

$oper= $_SESSION['valid_oper_id'];

$res = get_kurs($id,$oper);

т.к. на момент перехода по ссылке может произойти так, что администратор запретил данному оператору доступ. Затем если доступ по прежнему имеется, то в переменную $res_2 сохраняется подробная информация о доступе оператора к данному курсу:

$res = $res->fetch_assoc();

$res_2 = $res;

Далее проверяем конкретно имеет ли оператор доступ к лимитам курса на пересдачу, и если это так то выводим тэг формы, которая взаимодействует со скриптом ch_limit.php.

if($res_2['lim'])

echo '<form method="post" action="ch_limit.php"><input type="hidden" name="id" value='.$id.'>';

По окончании вывода информации о лимитах, в случае разрешенного доступа выводится кнопка «Применить»:

if($res_2['lim']) echo '<tr><td align="right"><input type="submit" value="Применить">&nbsp</td></tr>';

С помощью данной кнопки оператор будет иметь возможность изменять лимиты на пересдачу. По нажатию кнопки введённые данные передаются скрипту ch_limit.php. Если же оператор не имеет данного доступа, то кнопка «Применить» не отобразится, и оператор всего лишь может просматривать лимиты.

Следующим важным моментом является вывод меню для добавления вопросов. Это следующие строки всё той же функции show_kurs_access(output.php):

if($res_2['ins'])

echo '<table width="600"><tr><td><a target="_blank" title="Добавление вопроса по выбранному курсу" href=oper.php?typ=new_quest&id='.$id.'>Добавить вопрос</a></td></tr></table>';

всё просто - проверяется имеет ли оператор доступ на вставку вопросов ($res_2['ins']) то выводится ссылка «Добавить вопрос».

Ну и наконец-то, список вопросов. При выводе списка по умолчанию доступно меню «Подробно», но также может быть доступным меню «Удалить», разумеется если оператор имеет доступ на удаление. Вывод вопросов происходит в той же функции, что и вывод лимитов. Здесь главной строчкой проверки является строка:

if($res_2['del']) $del = '&nbsp;&nbsp;<a href="del_quest.php?id='.$row['q_id'].'"><font color="red" face="Verdana" size="2">Удалить';

else $del='';

Если оператор имеет доступ на удаление ($res_2['del']), то в переменную $del заносится тэг вывода ссылки для удаления вопроса. Эта ссылка передаёт скрипту del_quest.php параметр id (идентификатор вопроса), который нужно удалить. Далее при выводе меню вопроса к стандартному пункту «Подробно» просто присоединяется строковая переменная $del (либо она пуста, либо она содержит ссылку на удаление):

echo '<tr><td align="right"><a target="_blank" href="oper.php?typ=quest_info&id='.$row['q_id'].'"><font face="Verdana" size="2">Подробно</a>'.$del.'</td></tr></table>';

Ссылка «Подробно» здесь даёт возможность просмотреть информацию о конкретном вопросе в новом окне. Причём в этом новом окне опять же в зависимости от доступа оператора может появиться кнопка «Применить» дл редактирования вопроса. Код проверки доступа на редактирование практически идентичен с кодом проверки доступа к лимитам курса, поэтому рассматривать его нет особой надобности.

Отдельного внимания при работе оператора занимает проверка вводимых данных и корректное отображение в браузере. Известно, что взлом любой вэб-системы зачастую происходит из-за того, что разработчики допускают на первый взгляд мелкие недочёты при манипулировании с данными. Рассмотрим возможности взлома на примере нашего портала. Допустим при вводе вопроса не происходит никакой обработки текстовых данных вопроса, тогда злоумышленник просто напросто введёт в поле текста вопроса небольшой скрипт для взлома. Далее этот скрипт будет сохранён в БД как обычный вопрос, но при отображении в браузере этот якобы «обычный» вопрос будет уже не просто отображаться, а производить определённые действия, непредусмотренные разработчиками. Не трудно представить, что будет если такое допустить. Для таких случаев в языке PHP был введён ряд специальных операторов, ограничивающих те или иные действия. Эти операторы встречаются в листингах тестового портала практически везде, где происходят манипуляции с текстовыми данными.

Первый и очень часто встречающийся оператор - это оператор «Addslashes». Нужен он для того, чтобы отменять некоторые управляющие структуры, к таковым относятся кавычки (одинарные и двойные), символ обратной косой черты (\) и символ NULL. Эти символы вполне могут быть частью текста, но при занесении такого текста в БД, могут возникнуть проблемы неправильной интерпретации этих символов со стороны СУБД “MySQL”. Поэтому до сохранения подобного рода текстовых данных в БД следует применять этот оператор. Разумеется данные будут сохранены в несколько ином виде, поэтому для правильного отображения таких данных в браузере надо преобразовать их к первоначальному виду с помощью оператора stripslashes - который является полным противодействием оператору addslashes. Следующий очень полезный оператор, который часто бывает нужен для фильтровки данных это оператор - striptags(). Этот оператор полностью удаляет из передаваемой ему строки все HTML- и PHP-дескрипторы, что не позволит создавать сценарии внутри данных, которые сервер передаёт для отображения браузеру. Допустим переменная $str содержит следующий текст: