#28622 closed Cleanup/optimization (fixed)
Allow password reset token to expire in under a day
Reported by: | Nijamudeen | Owned by: | Hasan Ramezani |
---|---|---|---|
Component: | contrib.auth | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Zach Liu | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Currently, the settings only has PASSWORD_RESET_TIMEOUT_DAYS for expiring token, which means it is impossible to set the timeout to hours/minutes.
In many applications a day is far too long and doesn't meet security requirements
It should be possible to configure it using a timedelta for arbitrary expires
Change History (15)
comment:1 by , 7 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 7 years ago
Cc: | added |
---|---|
Needs documentation: | set |
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 7 years ago
I think using PASSWORD_RESET_TIMEOUT which takes seconds makes better sense. To support backward compatibility, I think we should keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use PASSWORD_RESET_TIMEOUT when provided. Does it sound like a good idea?
Also currently token is made of days, so after change it should be made of seconds I think.
follow-up: 6 comment:4 by , 7 years ago
Supporting PASSWORD_RESET_TIMEOUT_DAYS
during the deprecation period makes sense but it should eventually be supersed by PASSWORD_RESET_TIMEOUT
. I suggest you take a look at how the MIDDLEWARE_CLASSES
to MIDDLEWARE
transition was handled to figure out how this should be done.
comment:5 by , 7 years ago
Before coding, please get a consensus on how to proceed on the DevelopersMailingList. I like readability benefits of the timedelta
proposal (compared to interpreting a number of seconds in a settings file, even if that could be somewhat mitigated by writing PASSWORD_RESET_TIMEOUT = 60 * 60 * 24 * 3
) but I'm unsure on the best approach.
comment:6 by , 7 years ago
Replying to Simon Charette:
Supporting
PASSWORD_RESET_TIMEOUT_DAYS
during the deprecation period makes sense but it should eventually be supersed byPASSWORD_RESET_TIMEOUT
. I suggest you take a look at how theMIDDLEWARE_CLASSES
toMIDDLEWARE
transition was handled to figure out how this should be done.
Hi Simon, you mentioned MIDDLEWARE_CLASSES to MIDDLEWARE transition, can you point me to where I can find the reference? Thanks.
comment:8 by , 7 years ago
Component: | Core (Other) → contrib.auth |
---|---|
Has patch: | set |
Type: | New feature → Cleanup/optimization |
Please uncheck "Needs documentation" if it's added to the patch.
comment:9 by , 6 years ago
Hello,
About the token generation, is there any reason that is only attached to resseting password feature ?
Shouldn't be usefull in many other cases?
I mean, this can be helpful in many other cases that need temporary auto-login through the URL.
comment:10 by , 5 years ago
Needs documentation: | unset |
---|---|
Owner: | changed from | to
comment:11 by , 5 years ago
Patch needs improvement: | set |
---|
Not sure if we should allow non-integer values to be passed to
PASSWORD_RESET_TIMEOUT_DAYS
or deprecate the setting for a new one which is seconds based (PASSWORD_RESET_TIMEOUT
) but this requests make a lot of sense.