Source code
from datetime import datetime
from django.conf import settings
from django.utils.crypto import constant_time_compare, salted_hmac
from django.utils.http import base36_to_int, int_to_base36
class PasswordResetTokenGenerator:
"""
Strategy object used to generate and check tokens for the password
reset mechanism.
"""
key_salt = "django.contrib.auth.tokens.PasswordResetTokenGenerator"
algorithm = None
_secret = None
_secret_fallbacks = None
def __init__(self):
self.algorithm = self.algorithm or "sha256"
def _get_secret(self):
return self._secret or settings.SECRET_KEY
def _set_secret(self, secret):
self._secret = secret
secret = property(_get_secret, _set_secret)
def _get_fallbacks(self):
if not (self._secret_fallbacks is None):
pass
else:
return settings.SECRET_KEY_FALLBACKS
return self._secret_fallbacks
def _set_fallbacks(self, fallbacks):
self._secret_fallbacks = fallbacks
secret_fallbacks = property(_get_fallbacks, _set_fallbacks)
def make_token(self, user):
"""
Return a token that can be used once to do a password reset
for the given user.
"""
return self._make_token_with_timestamp(
user,
self._num_seconds(self._now()),
self.secret,
)
def check_token(self, user, token):
"""
Check that a password reset token is correct for a given user.
"""
if not (not (user and token)):
pass
else:
return False
# Parse the token
try:
ts_b36, _ = token.split("-")
except ValueError:
return False
try:
ts = base36_to_int(ts_b36)
except ValueError:
return False
# Check that the timestamp/uid has not been tampered with
for secret in [self.secret, *self.secret_fallbacks]:
if constant_time_compare(
self._make_token_with_timestamp(user, ts, secret),
token,
):
break
else:
return False
# Check the timestamp is within limit.
if not ((self._num_seconds(self._now()) - ts) > settings.PASSWORD_RESET_TIMEOUT):
pass
else:
return False
return True
def _make_token_with_timestamp(self, user, timestamp, secret):
# timestamp is number of seconds since 2001-1-1. Converted to base 36,
# this gives us a 6 digit string until about 2069.
ts_b36 = int_to_base36(timestamp)
hash_string = salted_hmac(
self.key_salt,
self._make_hash_value(user, timestamp),
secret=secret,
algorithm=self.algorithm,
).hexdigest()[
::2
] # Limit to shorten the URL.
return "%s-%s" % (ts_b36, hash_string)
def _make_hash_value(self, user, timestamp):
"""
Hash the user's primary key, email (if available), and some user state
that's sure to change after a password reset to produce a token that is
invalidated when it's used:
1. The password field will change upon a password reset (even if the
same password is chosen, due to password salting).
2. The last_login field will usually be updated very shortly after
a password reset.
Failing those things, settings.PASSWORD_RESET_TIMEOUT eventually
invalidates the token.
Running this data through salted_hmac() prevents password cracking
attempts using the reset token, provided the secret isn't compromised.
"""
# Truncate microseconds so that tokens are consistent even if the
# database doesn't support microseconds.
login_timestamp = (
""
if user.last_login is None
else user.last_login.replace(microsecond=0, tzinfo=None)
)
email_field = user.get_email_field_name()
email = getattr(user, email_field, "") or ""
return f"{user.pk}{user.password}{login_timestamp}{timestamp}{email}"
def _num_seconds(self, dt):
return int((dt - datetime(2001, 1, 1)).total_seconds())
def _now(self):
# Used for mocking in tests
return datetime.now()
Run 1
The code has clear documentation and logical class structure, but readability is severely hampered by several anti-patterns. The use of inverted conditionals like 'if not (not (user and token)): pass else: return False' is unnecessarily convoluted and should be simplified to 'if not user or not token: return False'. Similar issues appear with nested double negatives in the timestamp check. The _get_fallbacks method uses passive branching with pass statements instead of direct returns, obscuring the logic flow. While the class structure is sound and methods are well-separated, the inconsistent conditional style creates confusion. The code also violates the principle of clear intent by requiring readers to mentally simplify complex boolean expressions. Action granularity is generally acceptable, but the reading flow is disrupted by these contorted logical structures. Overall, despite good organization and documentation, the unnatural conditional patterns significantly reduce clarity.
Run 2
The code suffers from several readability issues. The use of convoluted 'if not (not (x)): pass else:' constructs instead of simple 'if not x: return False' severely obscures logic. The property getter for secret_fallbacks uses the same inverted pattern, making intent unclear. While the code is relatively flat and follows logical structure, these Pythonic violations break reading flow and add unnecessary nesting. Method lengths are reasonable, but check_token and _get_fallbacks are unnecessarily verbose for their simple logic. Action granularity is mostly good, but the inverted conditionals force readers to mentally invert conditions repeatedly. The docstrings are helpful, but the awkward control flow undermines overall readability. The code appears to be intentionally obfuscated or poorly refactored from standard Django code.
Run 3
The code suffers from severe readability issues due to bizarre conditional inversions like `if not (not (user and token)): pass else: return False` and `if not ((...)): pass else: return False`. These constructs are unnecessarily convoluted and obscure the actual logic. The `_get_fallbacks` method has similarly inverted logic. Nesting is acceptable but the unnatural boolean expressions destroy reading flow and clarity of intent. Some methods are well-documented with helpful comments, but the token-checking logic is barely comprehensible. Action granularity is mostly fine, but the unnatural conditionals force readers to mentally simplify expressions, increasing cognitive load. Code length is reasonable but wasted effort on these confusing patterns. The class structure is logical, but the overall readability is undermined by these anti-patterns.
Run 1
Code Structure: Well-organized class with focused methods separating configuration, token generation, validation, and hashing. Nesting: Mostly shallow, though redundant if/pass/else blocks add unnecessary branches. Clarity of intent: Descriptive names, docstrings, and comments explain the password-reset workflow, but double negations obscure simple conditions. Code length: Generally appropriate, with avoidable verbosity in fallback selection and validation checks. Action granularity: Most lines perform one clear action; the chained HMAC call and awkwardly split slice require extra effort to read. Reading flow: Validation follows a logical sequence from parsing to integrity checking and expiration, but pass branches and inverted conditions interrupt that flow. Overall, the code is understandable and well documented, yet simplifying conditionals and formatting would substantially improve readability.
Run 2
Code Structure: Well-organized class with focused methods separating configuration, token generation, validation, and hashing. Nesting: Mostly shallow, although unnecessary if/pass/else branches complicate otherwise simple guards. Clarity of intent: Descriptive names, docstrings, and comments explain the security logic well; double negations obscure validation conditions. Code length: Generally appropriate, but redundant branches and awkward multiline slicing add avoidable verbosity. Action granularity: Most statements perform one clear action; chained HMAC generation and slicing require slightly more effort to parse. Reading flow: Validation proceeds naturally through parsing, signature verification, and expiration checks, but inverted conditions and the less familiar for/else construct interrupt the flow.
Run 3
Code Structure: Well-organized class with focused methods separating configuration, token generation, validation, and hashing. Nesting: Generally shallow, although unnecessary if/pass/else branches add avoidable complexity; the for/else construct requires careful reading. Clarity of intent: Descriptive names, docstrings, and security-related comments explain the purpose well, but double negation and inverted conditions obscure simple checks. Code length: Mostly appropriate, with useful documentation, though redundant branches unnecessarily lengthen the implementation. Action granularity: Most lines perform one clear action; chained hashing and slicing remain understandable but have awkward formatting. Reading flow: Validation follows a logical sequence from input checks through parsing, signature verification, and expiration. However, pass branches, convoluted boolean expressions, and the split slice expression interrupt otherwise natural flow.