Пользователи портала: регистрация, авторизация и управление правами

Пользователи портала: регистрация,
авторизация и управление правами
Данный документ содержит предложения по реализации на образовательных
порталах подсистемы (модуля) "Пользователи портала", функциями которой
являются:
 регистрация пользователей с внесением ими персональных сведений;
 назначение пользователям прав на доступ к информации, внесение и
редактирование данных;
 управление доступом к информации, предоставляемой различными
функциональными модулями портала.
В разделе 1 рассматриваются задачи, которые должна, на наш взгляд, решать
данная подсистема. В разделе 2 вводятся основные понятия и предлагается
информационная модель подсистемы. В разделе 3 приводится краткая
информация о пилотной реализации подсистемы "Пользователи портала".
1. Задачи подсистемы "Пользователи портала"
Подсистема "Пользователи портала" предназначена для решения следующих
групп задач:
1.1. Сбор и статистическая обработка информации о пользователях
Наличие на портале базы данных, содержащий сведения о зарегистрированных
пользователях позволяет проводить анализ аудитории портала: распределение
пользователей по категориям (школьник, студент, преподаватель…), по полу и
возрасту, по регионам России (заметим, что анализ географии можно провести и
на основе информации об IP-адресах посетителей портала) и т.д. Разумеется,
адекватность результатов такого анализа зависит от того, насколько полны и
достоверны данные, вносимые пользователями о себе при регистрации. Кроме
того, на портале надо обеспечить мотивацию для того, чтобы посетители
регистрировались, а в дальнейшем при обращении к порталу проходили
авторизацию и работали в режиме зарегистрированных пользователей. Для
этого на портале зарегистрированным пользователям должны предоставляться
дополнительные по сравнению с анонимными посетителями возможности по
доступу к информации и использованию сервисов портала.
1.2. Предоставление зарегистрированным пользователям расширенных прав
Зарегистрированным пользователям, прошедшим авторизацию, могут быть
предоставлены расширенные по сравнению с анонимными посетителями
портала права на доступ к информации и использование сервисов портала.
Такая политика предоставления прав стимулирует рост базы
зарегистрированных пользователей портала. Это делает возможным
протоколирование действий пользователя при работе с информацией,
доступной только зарегистрированным пользователям, и последующий анализ
активности и интересов пользователей. Например, если доступ в библиотеку
портала разрешить только зарегистрированным пользователям, то возможен
будет сбор информации не только о том, какие публикации пользуются
наибольшей популярностью, но и о том, каков состав "читателей" виртуальной
библиотеки, какие категории пользователей обращаются к тем или иным видам
публикаций и пр. Внесение какой-либо информации на портал (размещение
сообщения в форуме, внесение на рассмотрение модераторов ресурса для
каталога и т.п.) целесообразно разрешать только зарегистрированным
пользователям, записывая в соответствующей базе данных сведения о том,
какой пользователь (ID пользователя) и когда (дата) внес ту или иную запись.
Примером сервиса, предоставляемого только зарегистрированным
пользователям, может быть сервис подписки на почтовые рассылки портала
(наличие в профиле пользователя e-mail избавляет от необходимости вводить
при подписке адрес электронной почты, а подписка сводится лишь к выбору
интересующих рассылок из предлагаемого перечня). Набор прав,
предоставляемых зарегистрированным пользователям, определяется логикой
каждого конкретного модуля портала.
1.3. Адаптация интерфейса к интересам пользователя
В профиле зарегистрированного пользователя возможно предусмотреть
параметры для адаптации интерфейса пользователя к его интересам
(кастомизации интерфейса), т.е. параметры, с помощью которых пользователь
может управлять формой и содержанием информации, выдаваемой в тех или
иных модулях портала. Например, пользовательский интерфейс может
различаться при настройки профиля на школьника, студента, учителя школы,
преподавателя вуза, управленца. В случае мультидисциплинарных порталов в
профиле можно предусмотреть выбор интересующей дисциплины (например,
математика, физика, химия или биология на естественнонаучном портале).
Пользователь должен иметь возможность отредактировать свой профиль и, в
частности, изменить настройки, влияющие на кастомизацию интерфейса.
Изменение интерфейса в зависимости от параметров профиля пользователя
реализуется в каждом модуле портала в зависимости от функций и содержания
конкретного модуля. Например, в модуле "Новости" в зависимости от категории
пользователя и его предметных интересов можно по умолчанию выдавать
соответствующую тематическую подборку новостей, а доступ к остальным
новостям предоставлять через имеющийся механизм поиска.
1.4. Назначение прав доступа в системе управления контентом портала
В работе по информационному наполнению портала должен принимать участие
большой коллектив, члены которого выполняют различные задачи по внесению
и обработке информации, имеют различные права и несут разную
ответственность. В идеальном случае вся работа по внесению контента, его
редактированию и управлению публикацией на портале должна быть
организована через административный веб-интерфейс, в котором разные
пользователи и группы пользователей, участвующие в работе над порталом,
должны иметь различные права, зависящие от их роли в портальном авторском
коллективе.
С точки зрения прав на внесение и редактирование информации, а также статуса
вносимой информации в таком коллективе можно выделить следующие типы
пользователей-создателей контента, перечисленные ниже в порядке роста прав:
Операторы, вносящие первичную информацию, которая подлежит
последующей обработке и не публикуется в открытом доступе. Права оператора
могут быть предоставлены зарегистрированному пользователю в одном или
нескольких модулях. Оператор может редактировать собственные записи до тех
пор, пока вышестоящий менеджер контента не запретил это, изменив статус
записей.
Редакторы, имеющие право просматривать и исправлять внесенную
операторами информацию, но не обладающие правом публикации
отредактированных записей в открытом доступе. Редактор может вернуть
оператору запись на доработку, отклонить запись или же отредактировать
запись и передать ее на утверждение выпускающему редактору (модератору).
Права редактора могут распространяться не на все записи, внесенные
операторами в том или ином модуле портала, а только на записи, внесенные
некоторой группой операторов.
Модератор (выпускающий редактор), имеющий право просматривать
предварительно отредактированные записи, возвращать их на доработку,
отклонять записи или утверждать их, открывая для публичного доступа на
портале. Права модератора могут распростаняться как на все записи,
обрабатываемые в том или ином модуле, так и только на записи, которые
подготовлены некоторой группой редакторов.
Администратор, имеющий полный набор прав по управлению информацией в
том или ином модулей, включая внесение записей, их редактирование и
присвоение им любого возможного статуса. Пользователь, имеющий права
администратора во всех модулях, является администратором портала в целом.
Перечисленный перечень "ролей" и их интерпретация не являются
исчерпывающими, а лишь иллюстрируют то, что в подсистеме "Пользователи
портала" следует предусмотреть возможность назначения различных прав по
управлению контентом. Интерпретация ролей, т.е. программная реализация
конкретного набора прав по внесению и изменению информации,
осуществляется в каждом конкретном модуле портала, а подсистема
"Пользователи портала" должна позволять присваивать пользователям наборы
атрибутов, позволяющих идентифицировать их как контент-менеджеров
(операторов, редакторов, модераторов, администраторов и т.д.) в тех или иных
модулях, и передавать эту информацию в модули. Заметим, что один и тот же
пользователь может иметь разные роли в различных модулях, в том числе
нескольких ролей в одном модуле.
2. Основные понятия и информационная модель подсистемы
Определим основные понятия, которые используются при дальнейшем
изложении материала, и приведем некоторые комментарии, связанные с этими
понятиями. Данные определения не претендуют на строгость и носят рабочий
характер.
Модуль портала – компонент программного комплекса портала, реализующий
определенный набор функций. Как правило, модуль имеет пользовательский
интерфейс для работы с контентом, предоставляемым этим модулем и
находящимся в публичном доступе, и административный интерфейс для
подготовки и управления контентом. При программной реализации модулей
соблюдаются общие принципы, заложенные в архитектуру программного
комплекса и касающиеся взаимодействия модулей, работы с базами данных и
пр.
Подсистема "Пользователи портала" - система регистрации и авторизации
пользователей портала, построенная как один из модулей портала по общим
правилам построения модулей портала. Главными объектами (сущностями), на
которых построена подсистема, являются пользователи, группы пользователей,
модули и сервисы. Назначение прав и реализация этих прав строятся путем
задания атрибутов этих сущностей и связей между ними. Подсистема имеет
структуру таблиц и логику работы с данными, позволяющие гибко управлять
правами пользователей в разных модулях портала (структура таблиц БД,
обеспечивающих работу подсистемы, рассмотрена в разделе 3).
Посетитель портала – любой пользователь Интернет, работающий с
контентом портала и не прошедший регистрацию.
Права на доступ к информации для тех или иных категорий пользователей
(посетитель, зарегистрированный пользователь, пользователь с правами
менеджера контента) определяются логикой работы каждого конкретного
функционального модуля портала. Поэтому в зависимости от реализации
модуля посетитель (т.е. "анонимный пользователь") может получить в нем
права на чтение любой информации (например, просмотр всех материалов в
модуле "Новости"), или права на чтение части информации (например, может
просматривать электронный каталог библиотеки портала, но не может
извлекать полнотекстовые материалы), или даже права на внесение записей в
базу данных (например, посетитель может принять участие в онлайновом
опросе, проголосовав через веб-форму ).
Зарегистрированный пользователь – - пользователь прошедший авторизацию
на портале путем ввода уникального имени и правильного пароля, полученных
на этапе регистрации.
Профиль пользователя – набор данных, характеризующих данного пользователя
(фамилия, имя, отчество, регион, личное резюме, принадлежность к той или
иной целевой аудитории портала, области интересов на портале и пр.). Часть
параметров профиля является обязательной и должна быть введена при
регистрации.
При регистрации посетитель портала заносит в базу пользователей свои
уникальное имя (логин), пароль и обязательный набор персональных данных, а
далее при последующих обращениях к порталу вводит логин-пароль и
приобретает после прохождения авторизации (проверка на соответствие
введенных логина-пароля имеющейся в базе информации) статус
зарегистрированного пользователя.
Данные, вносимые в профиль пользователя, могут быть использованы на
портале для решения следующих задач:
1) авторизациия посетителя в качестве зарегистрированного пользователя используются логин и пароль;
2) сбор статистической информации о зарегистрированных пользователях
портала – используются такие данные как регион, принадлежность к
определенной целевой аудитории портала (школьник, студент,
преподаватель…), возраст и другие данные, не являющиеся произвольным
текстом и допускающие формализованную смысловую обработку;
3) идентификация пользователя при его работе с коммуникативными
сервисами портала – например, отображение имени и фамилии в форумах,
гостевой книге и т.п.;
4) предоставление информации о пользователе посетителям портала в случае,
если пользователь хочет сделать эту информацию общедоступной –
используются ФИО, регион, резюме, ссылка на персональную страницу,
если таковая имеется и т.п.;
5) кастомизация интерфейса в модулях, предусматривающих изменение формы
и содержания предоставляемой информации в зависимости от указанных в
профиле пользователя областях интересов и принадлежности к той или иной
аудитории;
6) представление в административных интерфейсах информации о
пользователях-менеджерах контента, внесших или изменивших данные –
используются логин или имя-фамилия; поиск записей, внесенных или
модифицированных интересующим пользователем.
Конкретный набор данных, составляющих профиль пользователя, еще должен
быть уточнен и согласован с заинтересованными участниками работ по
созданию образовательных порталов. Поэтому ниже приводится лишь пример
возможного профиля, включающего следующие данные:
 Логин (уникальное имя пользователя). Предлагается использовать адрес
электронной почты. Во-первых, это обеспечивает уникальность
регистрационного имени, во-вторых, не требует дополнительного поля в
базе данных для хранения e-mail адреса, и, наконец, в-третьих, делает
синтаксически корректный e-mail адрес обязательным параметром профиля
пользователя.
 Пароль. Вводится пользователем (при заданных ограничениях на количество
и характер символов). Если пользователь забыл пароль, то он может быть
выслан по электронной почте на e-mail, указанный в качестве логина.
 Фамилия (обязательный параметр, при вводе проверяется разумность длины
и символов).
 Имя (обязательный параметр, при вводе проверяется разумность длины и
символов).
 Отчество (необязательный параметр).
 Тип пользователя (принадлежность к определенной аудитории – школьник,
студент, преподаватель и т.д.). Обязательный параметр. Используется для
статистического анализа аудитории портала. Выбирается из списка,
задаваемого таблицей возможных типов. Обязательный параметр. Должна
быть предусмотрена возможность выбора значения "иной тип".
 Тип пользователя, используемый для кастомизации интерфейса. Может
отличаться от предыдущего, если, например, преподаватель хочет
посмотреть на портал глазами студента. По умолчанию задается значение,
при котором не происходит кастомизации интерфейса и во всех модулях
портала данные будут выдаваться в "универсальном", не адаптированном к
типу пользователя виде.





Регион России. Обязательный параметр. Выбирается из списка 89 субъектов
РФ, формируемого на основе соответствующей таблицы "Регионы".
Предлагается географическую принадлежность пользователя, используемую
в первую очередь для статистического анализа состава аудитории портала,
задавать с помощью регионов, а не городов, чтобы избежать проблем с
пользователями из городов, не включенных первоначально в
соответствующую таблицу. Для пользователей из других стран выбирается
значение, указывающее на этот факт.
Страна. Обязательный параметр. Выбирается из списка "основных" стран,
формируемого на основе соответствующей таблицы. Если выбран какойлибо из регионов РФ, то автоматически присваивается "Россия".
Резюме пользователя. Необязательный параметр. Произвольная текстовая
информация, вводимая пользователем в окне ввода текста. Допускаются
переводы строк, применение html-тэгов для форматирования, вставка
гиперссылок на личные сайты и веб-страницы. Заводить в профиле
отдельные текстовые поля для указания организации, должностей, ученых
званий и т.п. считаем нецелесообразным, поскольку база данных
пользователей – это не база данных Персоналий (педагогов, научных
сотрудников, специалистов), представляющая интерес в качестве контента
портала. Все, что пользователь хочет кратко сообщить о себе, он может
указать в резюме. Но это наше мнение может быть предметом для
дискуссии.
Ссылка на личную страницу пользователя на портале. Необязательный
параметр. Речь идет о реализации на портале модуля "Персональные
страницы пользователей", предназначенного для предоставления
пользователям возможности создать по шаблону (нескольким шаблонам)
личные страницы путем заполнения веб-форм. Именно в этом модуле и
можетбыть представлена развернутая информация о пользователе, если он
сочтет целесообразным сделать это. На такой странице можно
предусмотреть размещение и фотографии, и разнесенной по отдельным
полям характеристики в стиле CV и т.д. В профиле будет находиться лишь
ссылка на такую страницу (в виде id записи в модуле "Персональные
страницы", относящейся к данному пользователю).
Интересы пользователя. Необязательный параметр, используемый для
кастомизации интерфейса. Задается как перечень предметных областей,
относящихся к содержанию портала и представляющих интерес для данного
пользователя. Выбирается из списка, формируемого из таблицы "Интересы
пользователя". Интересов у пользователя может быть несколько, поэтому
эти данные для профиля выбираются пользователем путем множественного
выбора из предложенного перечня (например, путем проставления отметок в
checkboxes), а в базе данных хранятся в вспомогательной таблице связей
"пользователи-интересы".
Заметим, что добавление в профиль любых текстовых и числовых атрибутов,
приводящих к появлению в соответствующей таблице базы данных (таблица
"Зарегистрированные пользователи") новых полей, не связанных с другими
таблицами, не представляет проблем. Включение же в профиль атрибутов,
значения которых берутся из других таблиц базы данных, и тем более
установление связей типа "один-ко-многим" (как это имеет место, например,
при задании интересов пользователя), требует более тщательной проработки,
особенно с точки зрения стандартизации требований к профилям пользователей
и обмену данными о пользователях порталов.
Зарегистрированный пользователь может при желании изменить любые
параметры своего профиля, в том числе логин и пароль. Неизменным остается
уникальный идентификатор (ID), присваиваемый в базе данных при
регистрации.
Права зарегистрированных пользователей, получаемые ими по умолчанию
(только за то, что они прошли регистрацию и работают под своими логинами), в
различных модулях могут как совпадать с минимальными правами посетителей
портала, так и отличаться от них в сторону расширения полномочий.
Выдача по умолчанию зарегистрированным пользователям дополнительных по
сравнению с анонимными посетителями прав имеет смысл, например, в тех
случаях, когда для портала важно отслеживать действия пользователей и
сохранять информацию о том, какой пользователь прочитал ту или иную
информацию, внес ту или иную запись. В ряде модулей выдаваемая
пользователю информация может зависеть от сформированного им при
регистрации профиля (например, самоидентификация пользователя в качестве
школьника, студента, преподавателя, научного сотрудника может привести к
соответствующей персонализации выдаваемой информации). Выдача
зарегистрированным пользователям расширенных прав целесообразна также
для стимулирования к регистрации и пополнению базы данных пользователей,
представляющей интерес для создателей портала.
Группа пользователей – поименованное подмножество зарегистрированных
пользователей. По умолчанию каждый пользователь после успешной
регистрации заносится в группу "общая". Другие группы создаются с целью
последующего управления работой объединенных в группу пользователей, или
же с целью сбора статистики и формирования отчетов по работе группы. Один
пользователь может входить в любое количество групп. В качестве примера
группы можно привести группу пользователей-редакторов, подготавливающих
для каталога портала описания интернет-ресурсов по какой-либо тематике.
Занести зарегистрированного пользователя в группу может модератор модуля
"Пользователи портала", имеющий права на занесение пользователей в свою
группу, или администратор данного модуля, имеющий право на включение в
любую группу. Создать новую группу и выдать права модератора группы может
администратор модуля "Пользователи портала".
Штамп записи – служебная информация, присутствующая в каждой из записей
базы данных, содержащей контент портала. Штамп записи включает пять
атрибутов:
 статус записи;
 ID пользователя, создавшего запись;
 дата создания записи;
 ID пользователя, внесшего последнее изменение в запись;
 дата последнего изменения записи.
Статус записи – служебный атрибут записи, используемый для управления
"жизненным циклом" записи на портале. Данный атрибут является
обязательным для любой записи, относящейся к контенту портала – новость,
библиографическая карточка в электронном каталоге библиотеки, сообщение в
форуме, реплика ведущего в гостиной, доклад в интернет-конференции,
карточка персоны или организации и т.д. В зависимости от значения статуса,
записи могут быть доступны для редактирования тем или иным категориям
пользователей с правами менеджеров контента, показываться или не
показываться в публичном пользовательском интерфейсе и т.п. При создании
новой записи и внесении ее в базу данных через веб-интерфейс запись сначала
принимает статус "рассматривается". Далее в процессе обработки этой записи
менеджерами контента статус записи может изменяться, отражая текущее
состояние записи.
Приведем предлагаемый набор возможных значений статуса записи с кратким
описанием типичной смысловой трактовки каждого из значений:
 рассматривается (присваивается при создании записи и показывает, что
запись находится в процессе рассмотрения менеджерами контента);
 отклонена (присваивается, когда запись рассмотрена и "забракована", т.е. ее
публикация на портале признана нецелесообразной);
 активна (присваивается утвержденным записям; поэтому если запись
содержит информацию, которая предназначена для публикации на портале,
то "активные" записи отображаются в публичном интерфейсе);
 блокирована (присваивается записям, которые изъяты из числа
рассматриваемых или активных и на которые требуется обратить внимание,
чтобы принять решение по их "дальнейшей судьбе");
 архивирована (присваивается записям, которые до этого имели статус
активных, чтобы придать им особый статус, например запретить их
модификацию всеми менеджерами контента; в качестве примеров
использования этого статуса можно привести работу с карточками
персоналий в случае смерти человека или карточками организаций в случае
ликвидации организации).
Присвоение статуса, его изменение и интерпретация осуществляются в модуле,
реализующем работу с соответствующими данными. Поэтому в каждом
конкретном модуле могут быть свои отличительные особенности в работе с
записями, включая различную трактовку перечисленных значений статуса.
Однако общие принципы использования атрибута "статус записи" сохраняются
во всех модулях.
Менеджер контента – пользователь портала, которому выдан набор прав,
отличающийся от набора прав, который получает по умолчанию любой
зарегистрированный пользователь, в сторону расширения полномочий по
внесению новой информации и/или модификации информации, содержащейся
на портале. Пользователь, являющийся менеджером контента в том или ином
модуле портала, получает доступ к административному интерфейсу, через
который он может вносить новые записи, редактировать или изменять статус
существующих записей.
Роль менеджера контента (или для краткости просто роль) – параметр,
используемый при определении прав, которые получает менеджер контента в
том или ином модуле портала. Предлагается в качестве базового принять
следующий набор возможных ролей, характеристика которых дана выше в
подразделе 1.4:
 оператор;
 редактор;
 модератор;
 администратор.
Права, задающие полномочия по работе с информацией, которыми обладает
менеджер контента с той или иной ролью, определяются логикой каждого
конкретного модуля портала. При формулировке этих прав определяются
следующие моменты:
1) может ли менеджер вносить новые записи;
2) какие записи (кем созданные, кем модифицированные, с каким статусом)
менеджер может редактировать;
3) какие значения статуса менеджер может присваивать записям в процессе
редактирования.
Приведем примеры одного из возможных подходов к распределению
полномочий менеджеров с перечисленными выше четырьмя ролями.
Например, оператору могут быть выданы права, допускающие внесение новых
записей и редактирование записей, которые создал он сам (это определяется по
штампу) и которые имеют статус "рассматривается"; при этом все записи,
созданные или модифицированные оператором сохраняют статус
"рассматривается".
Редактору могут быть выданы права, допускающие внесение новых записей;
редактирование записей со статусами "рассматривается", которые создал он сам
и операторы, входящие в ту же группу, что и редактор; присвоение записям
статусов "отклонена", "рассматривается", "блокирована".
Модератору могут быть выданы права, допускающие внесение новых записей;
редактирование записей с любыми статусами, если они созданы и
модифицированы им, операторами или редакторами, входящими в ту же
группу, что и модератор; присвоение записям любого возможного статуса.
Администратор имеет права на создание записей и модификацию любых
записей, а также придание им любого статуса, независимо от того, кто создал
или модифицировал ранее эти записи.
В разных модулях может использоваться различная логика управления
данными, поэтому интерпретация ролей с позиций определения конкретных
правил работы с данными может изменяться от модуля к модулю. Если
необходимую логику в плане разграничения полномочий не удается
реализовать с использованием четырех ролей, то количество ролей в системе
может быть увеличено. Однако опыт работы по ряду проектов показал, что
сочетанием четырех ролей с объединением пользователей-менеджеров контента
в группы удается решить все возникающие задачи по управлению контентом.
Права менеджера контента, т.е. права по управлению данными в том или ином
модуле, зарегистрированный пользователь получает путем выдачи ему одного
или нескольких сервисов менеджера.
Сервис менеджера (далее для краткости просто сервис) - это сводное понятие,
включающее в себя модуль, роль и группу пользователей. Путем выдачи
зарегистрированному пользователю сервиса определяется набор атрибутов, на
основе которого впоследствии модуль портала может строить логику работы с
пользователем, предоставляя ему те или иные возможности по вводу и
модификации данных. Как уже указывалось, каждый модуль сам программно
реализует необходимую функциональность работы с пользователем,
основываясь на наборе атрибутов, указанных в выданном пользователю
сервисе.
Необходимые сервисы создаются администратором модуля "Пользователи
портала". Введение нового сервиса заключается в создании в таблице сервисов
новой записи, содержащей следующие атрибуты:
 ID сервиса;
 имя сервиса (условное название, несущее смысловую нагрузку и
используемое в веб-интерфейсе для выдачи сервиса пользователю);
 ID модуля, на который распространяется данный сервис;
 ID роли менеджера контента, которую получает обладатель данного сервиса;
 ID группы пользователей, работой которой управляет обладатель сервиса.
Каждый сервис должен быть обеспечен программной реализацией в модуле
соответствующей логики работы с данными. Поэтому базовый набор сервисов,
включающий все возможные роли, для каждого модуля закладывается на этапе
проектирования системы одновременно с разработкой модуля. По мере
появления новых групп пользователей, участвующих в работе по
информационному наполнению портала, будут появляться новые сервисы,
отличающиеся от имеющихся только последним из перечисленных выше
атрибутов - группой.
Выдача сервисов зарегистрированным пользователям осуществляется в модуле
"Пользователи портала", и сделать это могут пользователи, которые имеют
соответствующие менеджерские права в этом модуле. Администратор модуля
"Пользователи портала" может поместить пользователя в любые группы и
выдать любые сервисы. Модератор модуля "Пользователи портала" может
выдать сервис с ролью "оператор" или "редактор" на модуль и на группу, где он
сам имеет сервис с ролью модератора.
Пользователь может получить любое количество сервисов (выдача сервисов
сводится по сути к создании таблицы, связывающей ID пользователя и ID
сервиса). Сервис может быть выдан на определенный период, т.е. при выдаче
сервиса фиксируется дата выдачи и может быть указана дата окончания
действия сервиса. Администратор модуля "Пользователи портала" может в
любой момент приостановить у любого пользователя действие выданного
сервиса, придав ему статус "блокирован". Модератор модуля "Пользователи
портала" может приостановить действие сервиса только в том случае, если этот
сервис выдан на модуль и группу, где он является модератором.
3. Реализация предложенной модели
Описанный выше подход к построению подсистемы "Пользователи портала"
реализован на практике. Спроектирована и создана соответствующая база
данных в среде СУБД PostgreSQL. Написаны PHP-скрипты модуля
"Пользователи портала", поддерживающие работу с этой базой данных через
веб-интерфейс и реализующие все рассмотренные выше задачи.
Публичный интерфейс подсистемы "Пользователи портала" решает задачи
регистрации новых пользователей, создания и изменения пользователем своего
профиля, получение пользователем информации о выданных ему сервисах и
группах, в которые он записан.
Административный интерфейс подсистемы позволяет получать отчеты о
зарегистрированных пользователях, группах и выданных сервисах; изменять
профили пользователей, блокировать зарегистрированных пользователей;
создавать группы и записывать пользователей в группы; создавать сервисы и
выдавать их пользователям, получать отчеты об авторизации пользователей с
правами менеджеров в других модулях портала (т.е. анализировать активность
менеджеров контента в различных модулях).
Для программной реализации логики работы с пользователями и их правами в
других модулях портала разработана соответствующая библиотека PHPфункций, осуществляющих необходимые запросы к базе данных. Таким
образом, программист, реализующий другие модули портала, не должен
непосредственно работать с таблицами, поддерживающими работу модуля
"Пользователи портала", а опирается на общие для всего портала системные
функции.
Ниже дан перечень таблиц, используемых для описания предложенной модели в
базе данных. Приведены фрагменты скрипта, создающего базу данных, с
комментариями к полям таблиц.
Таблица "Статусы записей" status_tbl
id_status integer not null, -- id статуса
name_sh varchar(10) not null, -- краткое наименование статуса
name varchar(20) not null, -- полное наименование статуса
constraint id_status primary key (id_status)
Таблица "Штамп записи" stamp_tbl (наследуется во всех других таблицах,
кроме основных справочных (словарных) таблиц, которые не заполняются через
веб-интерфейс)
id_status integer not null, -- id статуса
id_create_user integer not null, -- id пользователя, создавшего запись
d_create timestamp default 'now()', -- дата создания записи
id_update_user integer default NULL, -- id пользователя, сделавшего последнее
изменение записи
d_last_update timestamp default NULL, -- дата последнего изменения
comments text, -- комментарий к записи
constraint id_status foreign key (id_status) references status_tbl (id_status)
Таблица "Регионы" puser_region_tbl (содержит 89 регионов РФ)
id_region integer, -- id региона
name_sh varchar(25) not null, -- краткое наименование региона
name varchar(100) not null, -- полное наименование региона
constraint id_region primary key (id_region),
constraint region_name_sh unique(name_sh)
Таблица "Страны" puser_country_tbl (содержит перечень стран, дополняется
вручную администратором БД)
id_country integer, -- id страны
name_sh varchar(25) not null, -- краткое наименование страны
name varchar(100) not null, -- полное наименование страны
constraint id_country primary key (id_country),
constraint country_name_sh unique(name_sh)
Таблица "Типы пользователей" puser_position_tbl (классификация
пользователей с точки зрения принадлежности к типу аудитории – школьник,
студент, учитель, преподаватель, исследователь…)
id_position serial, -- id типа
name_sh varchar(10) not null, -- краткое наименование типа
name varchar(100) not null, -- полное наименование типа
constraint id_position primary key (id_position),
constraint position_name_sh unique(name_sh)
+ штамп записи
Таблица "Интересы пользователя" puser_interest_tbl
id_interest serial, -- id области интересов
name_sh varchar(10) not null, -- краткое наименование области интересов
name varchar(100) not null, -- полное наименование области интересов
constraint id_interest primary key (id_interest),
constraint interest_name_sh unique(name_sh)
+ штамп записи
Таблица "Модули портала" puser_module_tbl
id_module serial, -- id модуля
name_sh varchar(10) not null, -- краткое наименование модуля (nick name)
name varchar(100) not null, -- полное наименование модуля
constraint id_module primary key (id_module),
constraint module_name_sh unique(name_sh)
+ штамп записи
Таблица "Роли менеджеров контента" puser_role_tbl
id_role integer, -- id роли
name_sh varchar(10) not null, -- краткое наименование роли (nick name)
name varchar(100) not null, -- полное наименование роли
constraint id_role primary key (id_role),
constraint role_name_sh unique(name_sh)
Таблица "Зарегистрированные пользователи" puser_user_tbl
id_user serial, -- id пользователя
login varchar(40) not null, -- login name (вводится адрес электронной почты)
password varchar(80) not null, -- пароль
last_name varchar(100), -- фамилия
first_name varchar(100), -- имя
mid_name varchar(100), -- отчество
id_user_position integer, -- id типа пользователя
id_view_position integer, -- id типа пользователя для кастомизации интерфейса
id_region integer, -- id региона России
id_country integer, -- id страны
user_info text, -- резюме пользователя
id_pers_page integer, -- id записи о персональной странице (в модуле
"Персональные страницы пользователей"
constraint id_user primary key (id_user),
constraint login unique(login),
constraint name unique(first_name, last_name),
constraint puser_user_position foreign key (id_user_position)
references puser_position_tbl (id_position),
constraint puser_view_position foreign key (id_view_position)
references puser_position_tbl (id_position),
constraint puser_region foreign key (id_region)
references puser_region_tbl (id_region),
constraint puser_country foreign key (id_country)
references puser_country_tbl (id_country)
+ штамп записи
Таблица связей "Пользователи – интересы" puser_user_interest_tbl
id_user integer not null, -- id пользователя
id_interest integer not null, -- id области интересов
constraint puser_user_interest primary key (id_user, id_interest),
constraint puser_user_interest_user foreign key (id_user)
references puser_user_tbl (id_user),
constraint puser_user_interest_interest foreign key (id_interest)
references puser_interest_tbl (id_interest)
+ штамп записи
Таблица "Группы пользователей" puser_group_tbl
id_group serial, -- id группы
name_sh varchar(10) not null, -- краткое наименование группы
name varchar(100) not null, -- полное наименование группы
constraint id_group primary key (id_group),
constraint status foreign key (id_status) references status_tbl (id_status),
constraint group_name_sh unique(name_sh)
+ штамп записи
Таблица связей "пользователи-группы" puser_user_group_tbl
id_user integer not null, -- id пользователя
id_group integer not null, -- id группы
constraint puser_user_group primary key (id_user, id_group),
constraint puser_user_group_user foreign key (id_user)
references puser_user_tbl (id_user),
constraint puser_user_group_group foreign key (id_group)
references puser_group_tbl (id_group)
+ штамп записи
Таблица "Сервисы менеджеров" puser_srv_tbl
id_srv serial, -- id сервиса
name_sh varchar(15) not null, -- краткое наименование сервиса
name varchar(100) not null, -- полное наименование сервиса
id_module integer not null, -- id модуля
id_role integer not null, -- id роли
id_group_admin integer default null, -- id управляемой группы
constraint puser_id_srv primary key (id_srv),
constraint puser_srv_name_sh unique(name_sh),
constraint puser_srv_module foreign key (id_module)
references puser_module_tbl (id_module),
constraint puser_srv_role foreign key (id_role)
references puser_role_tbl (id_role)
+ штамп записи
Таблица связей "пользователи-сервисы" puser_srv_user_tbl
id_user integer not null, -- id пользователя
id_srv integer not null, -- id сервиса
start_work timestamp not null default 'now()', -- дата выдачи сервиса
stop_work timestamp default null, -- дата окончания действия сервиса
constraint puser_srv_user primary key (id_user, id_srv),
constraint puser_srv_user_start_work unique(id_user, id_srv, start_work),
constraint puser_user_srv_id_user foreign key (id_user)
references puser_user_tbl (id_user),
constraint puser_user_srv_id_srv foreign key (id_srv)
references puser_srv_tbl (id_srv)
+ штамп записи
Таблица "Протокол работы менеджеров" puser_log_tbl
id_user integer not null, -- id пользователя
id_srv integer not null, -- id сервиса
d_log timestamp not null, -- дата и время авторизации в модуле
log text, -- сообщение, генерируемое модулем при авторизации
constraint puser_log_user foreign key (id_user)
references puser_user_tbl (id_user),
constraint puser_log_srv foreign key (id_srv)
references puser_srv_tbl (id_srv)
+ штамп записи