Re: Make timeout property for PasswordResetTokenGenerator

[Carlton Gibson]

Hey Robert.

> ... the argument here is "we don't want to", but the reasoning behind
that is unclear ...

For me, the reasoning would be that we get several security reports against
Django pretty much every week, and the extent to which we make security
sensitive areas **generic** for the sake of only a subset of users
increases the attack surface, which makes these harder to contain and deal
with. (**Every** hook adds a maintenance cost, no matter how small. The
question is always whether it's worth it.)

The diff on django/contrib/auth/tokens.py is small:
https://github.com/django/django/pull/11302/files

I'm not sure we want to make PasswordResetTokenGenerator usable as a
generic token generator. (Use the signing tools to create your own no?)

Perhaps others will say that yes this is worth it (and then we come to a
consensus, or not) — but my original reply was attempting to expand the
reason for the original decision to turn it down.

C.










On Wed, 24 Aug 2022 at 15:53, 'Robert Musił' via Django developers
(Contributions to Django itself)  wrote:

> 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 
>> 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 

Re: Make timeout property for PasswordResetTokenGenerator

[Contributions to Django itself]

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  
> 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
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django 

Re: Make timeout property for PasswordResetTokenGenerator

[Carlton Gibson]

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 
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 <
> voloshchenkoalexan...@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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6458aad7056857164d976b1c7ce46bcd0249d292.camel%40gammascience.co.uk
> 
> .
>

-- 
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/CAJwKpyTL8n2wDqcA0TY33uZ_F3iro-NYw8vj_Mp4Y_htDqfHvw%40mail.gmail.com.

Re: Make timeout property for PasswordResetTokenGenerator

[Alexander Voloshchenko]

Hi Carlton!

I can understand what you're saying, and I don't think the TimestampSigner 
solution is bad

But again, it's a little unclear why in the end, in line 132 of 
https://github.com/django/django/blob/7e6b537f5b92be152779fc492bb908d27fe7c52a/django/contrib/auth/tokens.py#L132
 
we assign an object of class PasswordResetTokenGenerator to a variable 
named default_token_generator, so should it be the default way to create 
tokens? why then default_token_generator should generate tokens with a 
timeout limit depending on the variable PASSWORD_RESET_TIMEOUT?

and if somehow this class was meant to be a way to create tokens, why not 
put timeout as separate property? 

On Tuesday, August 23, 2022 at 12:45:59 PM UTC+2 carlton...@gmail.com 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/4f810acc-f2b4-4931-a84e-a59332a825f1n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/02973270-90d7-46ea-a471-d615a52c4f8fn%40googlegroups.com.

Re: Make timeout property for PasswordResetTokenGenerator

[Roger Gammans]

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 <
> voloshchenkoalexan...@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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6458aad7056857164d976b1c7ce46bcd0249d292.camel%40gammascience.co.uk.

Re: Make timeout property for PasswordResetTokenGenerator

[Carlton Gibson]

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 <
voloshchenkoalexan...@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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4f810acc-f2b4-4931-a84e-a59332a825f1n%40googlegroups.com
> 
> .
>

-- 
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/CAJwKpyTkzLNe9sWNVGKfMBvGwxCOKEDzr4EVHhHySo9ddXzXNw%40mail.gmail.com.

Re: Make timeout property for PasswordResetTokenGenerator

[Alexander Voloshchenko]

Hi Max!

Thanks for your answer

But honestly, I don't really understand how You can check if super returns 
false not from the last 'if'.
Now the function has 5 places where it can return False, and yes, we don't 
like the last case specifically. But to be honest I don't see a way to 
check the first 4 without copying them from the framework code to our 
project (which sounds a bit wrong for us and absolutely not what we would 
like to see in a project)

Maybe I misunderstood You and maybe You have time to expand the concept 
because now I can hardly imagine it without copying code from django into 
the project codebase.

On Monday, August 22, 2022 at 6:36:40 PM UTC+2 ma...@wpsoft.at wrote:

> Hi Alexander.
>
>  
>
> You can simply override ‘check_token’ to avoide this harcoded 
> settings.PASSWORD_RESET_TIMEOUT on the 57 line.
>
>  
>
> And for yours task it can be with super call  and after add additional 
> check.
>
>  
>
> It is only some additional lines:
>
>  
>
> MyСlassFromPasswordResetTokenGenerator(…):
>
>  
>
> MY_OWN_TIMEOUT = your_timeout
>
>  
>
> def check_token(self, *args, **kwargs):
>
> return super().check_token(*args, **kwargs) or 
> self._my_check_token_function_with_other_timeout(*args, **kwargs))
>
>  
>
> _my_check_token_function_with_other_timeout – should check if super 
> returns false not from last ‘if’ in PasswordResetTokenGenerator.check_token
>
>  
>
> For us it works without any problem.
>
>  
>
> Mit freundlichen Grüßen,
>
> DI Mag. Maxim Danilov
>
>  
>
> +43(681)207 447 76
>
> ma...@wpsoft.at
>
>  
>
> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com] 
> *On Behalf Of *Alexander Voloshchenko
> *Sent:* Monday, August 22, 2022 3:40 PM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Make timeout property for PasswordResetTokenGenerator
>
>  
>
> 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/4f810acc-f2b4-4931-a84e-a59332a825f1n%40googlegroups.com
>  
> 
> .
>

-- 
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/8c4e2089-6722-45d4-ae1b-26e04b75cf71n%40googlegroups.com.

RE: Make timeout property for PasswordResetTokenGenerator

[Danilov Maxim]

Hi Alexander.

 

You can simply override ‘check_token’ to avoide this harcoded 
settings.PASSWORD_RESET_TIMEOUT on the 57 line.

 

And for yours task it can be with super call  and after add additional check.

 

It is only some additional lines:

 

MyСlassFromPasswordResetTokenGenerator(…):

 

MY_OWN_TIMEOUT = your_timeout

 

def check_token(self, *args, **kwargs):

return super().check_token(*args, **kwargs) or 
self._my_check_token_function_with_other_timeout(*args, **kwargs))

 

_my_check_token_function_with_other_timeout – should check if super returns 
false not from last ‘if’ in PasswordResetTokenGenerator.check_token

 

For us it works without any problem.

 

Mit freundlichen Grüßen,

DI Mag. Maxim Danilov

 

+43(681)207 447 76

  ma...@wpsoft.at

 

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Alexander Voloshchenko
Sent: Monday, August 22, 2022 3:40 PM
To: Django developers (Contributions to Django itself) 

Subject: Make timeout property for PasswordResetTokenGenerator

 

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-developers+unsubscr...@googlegroups.com 
 .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4f810acc-f2b4-4931-a84e-a59332a825f1n%40googlegroups.com
 

 .

-- 
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/01d8b645%2451b33f90%24f519beb0%24%40wpsoft.at.