You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm looking for a way to create user accounts without a password and initiate the reset procedure without the extra work on front-end or user side – it's supposed to be an atomic operation from my API's POV. Such functionality would also be helpful when creating mass or time-based password resets. Unfortunately, there's quite some logic hidden in the ResetPasswordRequestToken's post that prevents one from doing so.
What do you think about extracting and exposing it for the programmatic use? I can imagine two ways it could be done at the moment:
create a public function of email and/or register a new signal handler
follow the UNIX philosophy mentioned in the README file a one step further and extract the core resetting functionality to a separate package so it could be used without DRF and only keep a thin layer of DRF-specific usage here.
I've already seen #97 which partially covers this but it also introduces a completely new concept of "registration tokens" which are not needed for the use cases presented above.
If we reach an agreement on the scope of the change, I'd be happy to work on it and submit a PR.
The text was updated successfully, but these errors were encountered:
I'm looking for a way to create user accounts without a password and initiate the reset procedure without the extra work on front-end or user side – it's supposed to be an atomic operation from my API's POV. Such functionality would also be helpful when creating mass or time-based password resets. Unfortunately, there's quite some logic hidden in the
ResetPasswordRequestToken
'spost
that prevents one from doing so.What do you think about extracting and exposing it for the programmatic use? I can imagine two ways it could be done at the moment:
email
and/or register a new signal handlerI've already seen #97 which partially covers this but it also introduces a completely new concept of "registration tokens" which are not needed for the use cases presented above.
If we reach an agreement on the scope of the change, I'd be happy to work on it and submit a PR.
The text was updated successfully, but these errors were encountered: