Совершенно похоже на процесс запроса нового пароля с помощью представлений django auth, когда пользователь регистрируется на моем сайте, он заполняет форму, которая создает пользователя с флагом is_active
, установленным на False
.
Затем администратору сайта отправляется электронное письмо для подтверждения регистрации. Письмо содержит две кнопки: «принять» и «отклонить». Когда администратор нажимает кнопку «принять», он переключает флаг is_active
на True
и отправляет электронное письмо пользователю, чтобы уведомить его о том, что его запрос был одобрен. В настоящий момент, если администратор нажимает «отклонить», все, что происходит, - это отправка пользователю электронного письма.
Моя проблема заключается в том, что при нажатии кнопки «Принять» токен, генерируемый 'token':token_generator.make_token(user)
остается в силе после использования ссылки. Это связано с тем, что токен генерируется 1. пользователем pk, 2. паролем пользователя ha sh, 3. датой последнего входа в систему и 4. текущим datetime
. Следовательно, разница между состоянием «до» пользователя (is_active=False
) и состоянием «после» пользователя (is_active=True
) неразличима для генератора токенов. Я хочу исключить возможность того, что администратор сайта будет нажимать кнопку подтверждения более одного раза и тем самым рассылать несколько писем о принятии.
Я мог бы решить эту проблему путем:
a) создания собственного токена класс генератора, который наследуется от класса генератора токена по умолчанию и переопределяет _make_hash_value(self, user, timestamp)
, чтобы включить is_active
в ha sh или
b) обновить last_login
для пользователя при нажатии ссылки.
a) По ощущениям это более правильный способ сделать это, но на самом деле это не помогает сделать токен недействительным при нажатии кнопки отклонения.
С другой стороны, б) кажется более хакерским, но может применяться как к опциям принятия, так и отклонения. Я мог бы потенциально изменить модель пользователя, чтобы иметь флаг, который говорит, что пользователь был отклонен, и затем использовать это в сочетании с методом а). Я вижу полезность наличия явного изменения базы данных, показывающего, когда пользователь был отклонен, но в то же время я совершенно не хочу менять модель пользователя.
Какой наилучший курс выбрать? Или, если есть какое-то лучшее решение, пожалуйста, дайте мне знать!