Hey Carlton,
I'm reading through the replies and I feel like I'm missing point
completely.
First some background - `PasswordResetTokenGenerator` is heavily referenced
over the web (or more accurately - the `default_token_genrator`) when it
comes to account activation. I personally believe the solution is pretty
genius for this particular use case, simplifies the flow without relying on
the persistence layer. The implementation is also well-contained within the
class so makes using it super simple.
When I use `default_token_generator` I'm however limited by two things -
the fields that make up the hash (user.pk, user.password, login_timestamp
and current timestamp) - which I can EASILY overwrite with
`_make_hash_value` and `PASSWORD_RESET_TIMEOUT_DAYS` which is NOT easily
overwritten, due to the method `check_token` having too many
responsibilities.
So the use case is definitely there, but the argument here is "we don't
want to", but the reasoning behind that is unclear - is it not worth to
maintain this piece of code because it's deprecated? This would be flagged
then, no? Or do you feel like it's already a concrete implementation given
its name ("PasswordResetTokenGenerator") - would the solution then be
abstracting the parts of it to a base class, would that be acceptable?
On Tuesday, 23 August 2022 at 13:47:45 UTC+2 carlton...@gmail.com wrote:
> Yes, likely.
>
> My point was (merely) that we **don't** want to add
> additional extension points to PasswordResetTokenGenerator.
>
> On Tue, 23 Aug 2022 at 12:58, Roger Gammans <rgam...@gammascience.co.uk>
> wrote:
>
>> Hi
>>
>> If it's intended as a reference implementation, then I would expect
>> PasswordResetTokenGenerator to use Signer or TimestampSigner internally
>> , but I was surprised to discover that it didn't use either.
>>
>> Isn't those entry points the better API to advise for use rather than the
>> direct use of hmac based algorithms?
>>
>> On Tue, 2022-08-23 at 12:45 +0200, Carlton Gibson wrote:
>>
>> Hi Alexander.
>>
>> I think the point from ticket #30423 is that we don't want to complicate
>> PasswordResetTokenGenerator in order to make it into a more general
>> purpose token generator.
>> Much better is for you to take inspiration from it to implement what you
>> need in your project. (It's the underlying signing code that you really
>> want to lean on Django for.)
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Mon, 22 Aug 2022 at 17:26, Alexander Voloshchenko <
>> voloshchen...@gmail.com> wrote:
>>
>> During project development our team needs to create several types of
>> tokens. One of them will be used in case of account reset password. The
>> second one is for account activation. Django itself has a good class for
>> token generation called PasswordResetTokenGenerator. And now for account
>> activation, we are using our own class called ActivationTokenGenerator,
>> a subclass of PasswordResetTokenGenerator with overridden
>> _make_hash_value method. And it works, but there is one problem. And
>> this problem is called "timeout". For now, every token created with
>> PasswordResetTokenGenerator will have timeout from
>> settings.PASSWORD_RESET_TIMEOUT variable and can be changed only by
>> changing this variable value. But what if we need different timeouts for
>> different tokens? And I don't think we want changing timeout for
>> *activation* token using a variable which is screaming about *password
>> reset* (PASSWORD_RESET_TIMEOUT), we would like to use smth called
>> ACTIVATION_TOKEN_TIMEOUT
>> So there is a solution: why not create a timeout property for
>> PasswordResetTokenGenerator class? Almost in the same way as it was done
>> with _secret and algorithm fields.So our development team come up with
>> an idea to create a PR which will add this functionality to the Django
>> project. But before this we decided to search similar solutions in django
>> PRs. And we found them! Ticket 30423
>> https://code.djangoproject.com/ticket/30423 sounds good enough, but it
>> was closed with wontfix label.So the question is: why not to add this
>> fine feature to the PasswordResetTokenGenerator ? And if people find
>> this useful - why not to merge one o the existing PRs?
>>
>> --
>>
> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-develop...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/6458aad7056857164d976b1c7ce46bcd0249d292.camel%40gammascience.co.uk
>>
>> <https://groups.google.com/d/msgid/django-developers/6458aad7056857164d976b1c7ce46bcd0249d292.camel%40gammascience.co.uk?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/3f42f83a-2090-4627-bbf1-1dd86df34913n%40googlegroups.com.
