48566 (Разработка интернет-приложения для организации электронной доски объявлений), страница 2

topic_id – значение идентификатора подраздела, на который оформлена подписка, тип поля int, index.

8. Таблица SESSIONS.

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

user_id – значение идентификатора пользователя в таблице USERS, тип поля int.

sid – идентификатор сессии авторизованного пользователя, тип поля text.

time – значение времени в UNIX-формате, по истечению которого не продленная сессия будет автоматически удалена из таблицы, тип поля bigint.

Связи между полями таблиц приведены на рис. 2.1 структурной схемы данных. Ключевые поля-идентификаторы помечены знаком “*”, типы используемых связей: “один ко многим” и “один к одному”.

Рис. 2.1 - Схема данных

3. Разработка схемы программы

Рассмотрим основные задачи и требования, предъявляемые к разрабатываемому приложению на уровне организации WEB-интерфейса:

1) интерфейс отображение разделов каталога и объявлений,

2) интерфейс аккаунта пользователя,

3) интерфейс аккаунта модератора,

4) интерфейс аккаунта администратора,

5) интерфейс подписки на почтовую рассылку,

6) интерфейс авторизации и регистрации пользователей.

На функциональном уровне:

1) первоначальная инсталляция приложения на сервере,

2) соединение с БД MySQL,

3) инициализация основных параметров каталога,

4) проверка на корректность значений переменных, принимаемых от пользователя,

5) вывод разделов и подразделов каталога, а также объявлений,

6) регистрация новых пользователей,

7) авторизация пользователей,

8) аутентификация пользователей с помощью механизма сессий и проверка прав доступа,

9) добавление, редактирование и удаление объявлений,

10) организация механизма почтовой подписки с запросом подтверждающего кода,

11) подписка на подразделы каталога, активация, деактивация и удаление адреса из рассылки,

12) рассылка объявлений на почтовые адреса подписчиков,

13) редактирование основных параметров приложения,

14) добавление и удаление пользователей,

15) установка и снятие прав доступа с пользователей,

16) автоматическое удаление объявлений по истечению срока жизни, удаление не продлённых пользовательских сессий, удаление не активированных адресов почтовой рассылки.

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

Рис. 3.1 - Функциональная структура программы

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

1) модуль инсталляции (с отображением интерфейса),

2) модуль соединения с БД MySQL,

3) модуль отображения разделов каталога и объявлений (с отображением интерфейса),

4) модуль регистрации новых пользователей (с отображением интерфейса),

5) модуль авторизации пользователей (с отображением интерфейса),

6) модуль аутентификации пользователей, основанном на механизме сессий,

7) модуль реализации аккаунта пользователя (с отображением интерфейса),

8) модуль реализации аккаунта администратора (с отображением интерфейса),

9) модуль реализации аккаунта модератора (с отображением интерфейса),

10) модуль реализации аккаунта подписки на почтовую рассылку (с отображением интерфейса).

4. Разработка алгоритмов

1) Алгоритм инсталляции.

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

Модуль-инсталлятор выполняет следующие действия:

а) создает новую БД или удаляет все таблицы в текущей БД, использующиеся приложением, если они уже были созданы;

в) создает таблицы с указанием всех необходимых полей и типов;

г) добавляет записи со значением базовых параметров в статические таблицы ACTION и OPTIONS.

г) запрашивает логин и пароль администратора, добавляет запись в таблицу USERS и установить права администратора.

2) Алгоритм отображения разделов и подразделов.

Для отображения списка разделов необходимо послать запрос на получение всех значений поля name из таблицы SUBJECT, где значение идентификатора раздела каталога topic = 0, и вывести результат на экран.

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

Для того чтобы записи сортировались в алфавитном порядке, все запросы дополняются директивой «ORDER BY name ASC». Если в текущем подразделе каталога присутствуют объявления нескольких типов, выводится вспомогательный список-фильтр с перечислением найденных типов, тогда пользователь может выбирать тот или иной тип объявлений, который должен выводиться на всех разделах и подразделах каталога.

3) Алгоритм отображения объявлений с применением фильтра на тип объявлений.

Для отображения объявлений берутся все значения полей таблицы MESSAGES, в которой значение поля topic_id совпадает со значением текущего идентификатора раздела каталога. Поскольку при отображении объявлений необходимо выводить ещё и контактную информацию об отправителе, а также тип объявления, в запрос вводятся дополнительные условия: значение поля user_id таблицы MESSAGES должно совпадать со значением идентификатора пользователя id таблицы USERS, а значение поля action_id – со значением поля id таблицы перечисления типов объявлений ACTION. Если пользователь применил фильтр на тип объявлений, запрос дополняется ещё одним условием: значение поля action_id должно соответствовать значению фильтра. Сортировка записей производится по полю id в порядке убывания, в результате чего вверху WEB-страницы каталога отображаются последние добавленные объявления.

4) Алгоритм ограничения числа объявлений, выводимых на одной WEB-странице.

Поскольку число объявлений, удовлетворяющих вышеприведённому запросу может быть слишком велико, для того чтобы не перегружать выводимые WEB-страницы используется алгоритм ограничения числа объявлений и формирование так называемой линейки – ссылок на страницы, содержащие результаты запроса. Для этого с помощью директивы COUNT предварительно подсчитывается количество строк в результирующем запросе, причём приложение запрашивает у БД именно число строк в нужном запросе, а не результат запроса, тем самым экономя время обмена данными и трафик (в случае если БД находится на другом удалённом сервере). По полученному значению определяется, нужно ли формировать линейку или нет. Если нужно, запрос дополняется директивой LIMIT с перечислением диапазона выводимых значений в результирующем запросе. Диапазон представляет собой некоторое начальное значение указателя на «окно» и максимальный размер этого «окна». Таким образом, результат запроса делится на «окна» и не перегружает выводимые страницы. Пользователь может выбирать для просмотра то или иное «окно», при этом само содержание запроса не изменяется, меняются лишь границы диапазона.

5) Алгоритм передачи значения фильтра при переходах по ссылкам каталога.

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

6) Алгоритм регистрации новых пользователей.

Регистрация пользователя происходит в следующей последовательности: на запрос программы пользователь вводит логин, пароль и контактную информацию о себе или об организации, которую он представляет на доске объявлений. Для удобства работы администратора со списком логинов пользователей проводится проверка на допустимый набор символов, состоящий только из английских букв и цифр. Для того чтобы исключить регистрацию пользователей с одинаковыми логинами, необходимо сделать проверку по полю login таблицы USERS. После вышеперечисленных проверок вычисляется хэш-код пароля пользователя. Хэш-код представляет собой 32-х символьную последовательность, вычисленную по алгоритму «MD5 Message-Digest Algorithm» (разработка корпорации RSA Data Security, [3]). Полученная последовательность является уникальной для символьной строки пароля пользователя, т.е. вероятность того, что два одинаковых пароля дадут одинаковый хэш-код, стремится к нулю. Основное преимущество кодирования по алгоритму MD5 – это невозможность обратного восстановления первоначальной символьной строки (пароля) по полученному хэш-коду. Вся полученная информация добавляется в поля login и password таблицы USERS, значение поля access устанавливается равным 1, что означает «права доступа на уровне пользователя».

7) Алгоритм авторизации пользователей.

Пользователю выводится форма для запроса логина и пароля, после ввода значений вычисляется хэш-код пароля и посылается запрос к таблице USERS. Если у пользователя есть учётная запись, соответствующая этим значениям, то он считается авторизованным. Прочитав значение поля id, мы получим идентификатор пользователя. Затем необходимо позаботиться об информации для модуля аутентификации, для этого используется таблица сессий SESSION. Поле user_id этой таблицы содержит значения идентификаторов пользователей с открытыми сессиями. Поскольку на один и тот же логин может быть открыта только одна сессия, сначала из таблицы удаляется запись с полученным ранее значением идентификатором авторизованного пользователя. Далее случайным образом генерируется 20-символьная строка, которую обозначим как «код сессии авторизованного пользователя». Именно эта строка, а не хэш-код пароля пользователя (или тем более его истинный пароль) впоследствии будет передаваться между приложением на сервере и браузером клиента. Код сессии заносится в поле sid. В целях безопасности, для того чтобы открытые сессии имели ограниченный во времени срок действия, каждой сессии назначается время жизни time, равное текущему значению времени на сервере плюс 60 минут. В случае, если пользователь ввёл ошибочные данные и его учётная запись не была обнаружена, ему предлагается либо заново пройти процедуру авторизации, либо зарегистрировать новую учётную запись.

8) Алгоритм аутентификации пользователей.

Обращение к данным идёт через запросы к таблице сессий SESSIONS и таблице пользователей USERS. Сначала идёт попытка считать 20-х символьный хэш-код сессии авторизованного пользователя, передаваемый между приложением и авторизованным клиентом. Затем из таблицы SESSIONS удаляются все сессии с просроченным временем жизни, если таковые имеются. Для этого текущее значение времени на сервере сравнивается со значением поля time.

Из таблицы SESSIONS получаем значение id той записи, у которой значение sid совпадает с хэш-кодом сессии авторизованного пользователя, после чего из таблицы USERS выбирается учётная запись с полученным идентификатором пользователя id. Эта учётная запись содержит идентификатор пользователя, логин, контактную информацию и права доступа, которая в дальнейшем используется различными модулями, требующими аутентификацию.

Далее продлевается срок жизни сессии: обновляется значение поля time.

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

Если пользователь закрывает сессию самостоятельно, происходит немедленное удаление записи из таблицы SESSIONS.

9) Алгоритм добавления новых объявлений.

Сначала идёт проверка максимально допустимой длины объявления, значение которой хранится в одной из записи таблицы OPTIONS. Объявления короче пяти символов также считаются недопустимыми. Поскольку сообщение может содержать недопустимые HTML-тэги, происходит замена таких тэгов на их «безопасные» эквиваленты.

Из таблицы MESSAGES удаляются сообщения, у которых истёк срок жизни, затем добавляется новая запись со значением полей topic_id, равному идентификатору текущего подраздела каталога доски объявлений в таблице SUBJECT; user_id, указывающим на идентификатор пользователя, отправившего объявление в таблице USERS; action_id, указывающим на идентификатор типа сообщения в таблице ACTION; time, равный значению текущей даты; time_live, обозначающим срок жизни объявления, и text, содержащий текст самого объявления.

В случае невыполнения условий проверок объявление в БД не заносится.

10) Алгоритм реализации механизма подписки на почтовую рассылку с запросом подтверждающего кода.

У авторизованного пользователя запрашивается почтовый адрес, причём происходит проверка на синтаксис (наличие знака «@» и «.»). Если в таблице MAIL в поле user_id уже содержится идентификатор данного пользователя и значение поля activation не равно «1» или «0», что указывает на то что рассылка на этот адрес находится в процессе подтверждения, выводится соответствующее сообщение и форма запроса подтверждающего кода, процесс регистрации прерывается (если значение поля activation равно «1» или «0», что указывает на то что у пользователя уже есть активированный почтовый адрес, процесс регистрации прерывается без вывода каких-либо форм). Иначе случайным образом генерируется число, которое заносится в таблицу MAIL поля activation. Это же число высылается на указанный почтовый адрес. В поле time заносится срок жизни записи, по истечению которого неподтвержденная рассылка будет удалена из таблицы.

При подтверждении рассылки, код, вводимый пользователем в форму запроса сравнивается со значением поля activation, в случае совпадения это значение заменяется на «1», что означает активацию рассылки. Пользователь может временно приостановить рассылку, при этом значение поля устанавливается в «0».

11) Алгоритм управления подпиской на подразделы каталога доски объявлений.