Регистрация на курсе

При использовании системы ролей существует проблема разграничения прав между различными курсами, которые доступны различным пользователям с одинаковыми ролями. Например, два различных пользователя с ролью «ROLE_STUDENT» должны иметь различный доступ, если принимают участие в разных курсах.

Для решения данной проблемы используется подход регистрации пользователей на курсе. Данная регистрация может быть применена к пользователям с ролями «ROLE_STUDENT» или «ROLE_PROFESSOR». Каждый пользователь может быть участником определенного курса, при этом данная информация сохраняется в базе данных.

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

  • 1. «/api/assignments/getAllResultsById» - проверка регистрации преподавателя на данном курсе;
  • 2. «/api/assignments/getAttemptsById» - проверка регистрации студента на данном курсе;
  • 3. «/api/assignments/triggerAssignmentById» - проверка регистрации студента на данном курсе.

Сохранение пароля пользователя

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

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

Для решения данной проблемы используется подход хэширования пароля с использованием «соли» (salt) [44] - случайной последовательности символов, используемой при хэшировании наряду с изначальным паролем. Соли, при этом, могут храниться в открытом виде вместе с хэшированными паролями, так как даже в случае их утечки, злоумышленнику придется подбирать пароль с заданной солью путем перебора, что делает расшифровку пароля практически невозможной.

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

 
< Пред   СОДЕРЖАНИЕ   Загрузить   След >