Изменения в системе аутентификации пользователей
Цель
Изменения внесены в рамках реализации концепции «единого входа» в систему тестирования и избавления от дублирования данных в БД.
Изменения в схеме данных
Следующие таблицы в БД предполагается использовать для хранения информации об аутентификации и авторизации.
- olympiad. В таблице olympiad не предполагается существенных изменений, но на нее ссылаются другие таблицы.
- team. Новая таблица для хранения информации о командах. Столбцы: id, title.
- user. В таблице user остается только информация, необходимая для аутентификации пользователя («login, password), восстановления пароля («email) и прочая информация о пользователе, не привязанная к конкретной олимпиаде.
- user_olympiad. Содержит информацию, привязывающую пользователя к конкретной олимпиаде: внешний ключ к записи об олимпиаде («olympiad»), ссылку на привелегии пользователя в этой олимпиаде (priv), ссылку на команду («team», может быть null)
- priv. Привелегии пользователя в конкретной олимпиаде.
Сценарии
- Индивидуальные соревнования. В таблице user_olympiad отсутствует ссылка на team
- Командные соревнования. В таблице user_olympiad участники одной команды имеют ссылки на одну запись в таблице team
- Жюри/тренеры. Не привязаны к команде (Или привязаны в выделенной команде Jury, или к одной из выделенных команд). Члены жюри, как правило, привязаны к нескольким олимпиадам (например, тренировкам).
- Команды в такой схеме не привязаны к какой-либо конкретной олимпиаде, поэтому одна команда может участвовать в нескольких олимпиадах (Участники команды будут иметь записи в таблице user_olympiad для каждой из олимпиад)
- «Автоматически» создаваемые пользователи в системе. Используется для проведения соревнований. В этом случае создаваемые пользователи не привязываются к уже существующим (хотя, возможно следует предусмотреть возможность «сливать» разных пользователей в одного)
- Пользователь может создавать команды и «приглашать» в него других зарегистрированных пользователей (? требует доработки)
- Восстановление пароля работает стандартным способом – через email.
- Доступ к системе регулируется специальной привилегией (например, p_login). ПРивилегия проверяется при каждом обращении к системе (при каждом запросе).
Изменения формы авторизации
ввод email или логин, ввод пароля. Т.к. у нас все равно email однозначно определяет пользователя, то это будет удобнее