The methodology in this library also works great for creating registration tokens. These are useful in the case where a user cannot signup themselves, but need an account created for them, and then are notified to sign up and create a password. This would be applicable in most business facing team apps.
Solution
Add function create_registration_token(user) that creates a registration token for a user where .has_usable_password() is False. If any other tokens exist for the targeted user, delete them.
Update get_password_reset_token_expiry_time to change the expiry time based on if the token being queried is a reset token or a registration token.
Require boolean variable register to be passed in the /reset_password/confirm/ request. If True, we are verifying a registration token, if False, we are verifying a reset token.
Referenced / Requested
Mentioned that this functionality could be helpful in #52 by @anx-ckreuzberger. (This PR does not address the issue itself, but the comment)
I don't think that this is a use-case that should be implemented within django-rest-passwordreset.
Re-enabling tokens is also sub-optimal, I would recommend to change the expiry time based on token type (e.g., you could have two token types, one for registration and one for password_reset).
As I'm time-constraint on supporting this library I would like to keep the footprint as small as possible, and not introduce new features.
I'll keep this issue open for others to comment on this, and maybe someone will create a fork that supports this behaviour.
Problem
The methodology in this library also works great for creating registration tokens. These are useful in the case where a user cannot signup themselves, but need an account created for them, and then are notified to sign up and create a password. This would be applicable in most business facing team apps.
Solution
Add function
create_registration_token(user)
that creates a registration token for a user where.has_usable_password()
is False. If any other tokens exist for the targeted user, delete them.Update
get_password_reset_token_expiry_time
to change the expiry time based on if the token being queried is a reset token or a registration token.Require boolean variable
register
to be passed in the /reset_password/confirm/ request. If True, we are verifying a registration token, if False, we are verifying a reset token.Referenced / Requested
Mentioned that this functionality could be helpful in #52 by @anx-ckreuzberger. (This PR does not address the issue itself, but the comment)