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 a(self):
return self._secret or settings.SECRET_KEY
def b(self, k):
self._secret = k
secret = property(_get_secret, _set_secret)
def c(self):
if self._secret_fallbacks is None:
return settings.SECRET_KEY_FALLBACKS
return self._secret_fallbacks
def d(self, l):
self._secret_fallbacks = l
secret_fallbacks = property(_get_fallbacks, _set_fallbacks)
def e(self, m):
"""
Return a token that can be used once to do a password reset
for the given user.
"""
return self.g(
m,
self.i(self.j()),
self.secret,
)
def f(self, n, o):
"""
Check that a password reset token is correct for a given user.
"""
if not (n and o):
return False
# Parse the token
try:
p, q = o.split("-")
except ValueError:
return False
try:
r = base36_to_int(p)
except ValueError:
return False
# Check that the timestamp/uid has not been tampered with
for s in [self.secret, *self.secret_fallbacks]:
if constant_time_compare(
self.g(n, r, s),
o,
):
break
else:
return False
# Check the timestamp is within limit.
if (self.i(self.j()) - r) > settings.PASSWORD_RESET_TIMEOUT:
return False
return True
def g(self, t, u, v):
# timestamp is number of seconds since 2001-1-1. Converted to base 36,
# this gives us a 6 digit string until about 2069.
w = int_to_base36(u)
x = salted_hmac(
self.key_salt,
self.h(t, u),
secret=v,
algorithm=self.algorithm,
).hexdigest()[
::2
] # Limit to shorten the URL.
return "%s-%s" % (w, x)
def h(self, y, z):
"""
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.
A = (
""
if y.last_login is None
else y.last_login.replace(microsecond=0, tzinfo=None)
)
B = y.get_email_field_name()
C = getattr(y, B, "") or ""
return f"{y.pk}{y.password}{A}{z}{C}"
def i(self, D):
return int((D - datetime(2001, 1, 1)).total_seconds())
def j(self):
# Used for mocking in tests
return datetime.now()
Run 1
The code is heavily obfuscated, rendering it nearly unreadable. Methods have been renamed from expressive names like '_make_token_with_timestamp' to meaningless single-letter identifiers ('a', 'b', 'g'). Properties are broken by references to non-existent private methods ('_get_secret' vs 'a'). This destroys clarity of intent and reading flow. Extreme nesting in 'f' and dense string formatting in 'g' further impede comprehension. The original logic is recognizable (Django token generator), but the mangled naming makes verification and maintenance extremely error-prone.
Run 2
This code is extremely unreadable due to deliberately obfuscated naming and severely degraded structure. Methods are renamed to meaningless single letters (a through j) and variables to arbitrary symbols (m, n, o, p, q, etc.), completely obscuring their intent. While the original logic (Django's password reset token generator) is logically sound and flat, this version destroys clarity of intent, reading flow, and action granularity. Comments explain what the code does, but they conflict with the cryptic identifiers, making the code harder to follow rather than easier. The class and docstrings remain descriptive, but the method and variable names undermine comprehension. Structure is superficially organized but semantically tangled. Nesting is limited, but that does not compensate for the unreadable identifiers. Code length is close to original, but every action requires cross-referencing names. This would be borderline unmaintainable for any developer.
Run 3
The code is severely unreadable due to obfuscated method names (a, b, c, d, e, f, g, h, i, j) that completely hide their purpose. Parameters use single or uninformative variable names (m, n, o, p, q, r, s, t, u, v, w, x, y, z, A, B, C, D), making the logic almost impossible to follow without extensive guessing. The class likely mimics Django's PasswordResetTokenGenerator, but the renaming destroys all clarity of intent. Structure is moderate, with some nesting in token validation, but the naming is the primary failure across criteria such as clarity of intent and reading flow. Although line length is reasonable and one action per line is mostly followed, the absurd naming makes the code effectively unreadable and unmaintainable.
Run 1
Code Structure: Responsibilities are logically separated into small methods, but property declarations reference undefined accessor names, disrupting coherence. Nesting: Mostly shallow, with early returns simplifying validation; the loop-else requires some attention. Clarity of intent: The class name, docstrings, and comments explain password-reset behavior, but single-letter method and variable names severely obscure individual operations and data roles. Code length: Implementation is reasonably concise, although the long explanatory docstring and awkwardly split slicing add reading overhead. Action granularity: Most statements perform one action, with only a few chained expressions combining steps. Reading flow: Generation, validation, hashing, and time helpers follow a sensible sequence, but opaque names force repeated cross-referencing, and mismatched property accessors interrupt understanding.
Run 2
Code Structure: Responsibilities are logically separated into small class methods, but property declarations reference undefined getter/setter names, disrupting coherence. Nesting: Mostly shallow, with early returns keeping validation straightforward; the loop-else requires extra attention. Clarity of intent: Docstrings and comments explain password-reset behavior well, but single-letter method and variable names obscure roles and relationships. Code length: Generally concise, although extensive documentation and awkward multiline slicing add visual bulk. Action granularity: Most lines perform one clear action, with reasonable separation of parsing, verification, and expiration checks. Reading flow: The overall generation and validation sequence is natural, but opaque calls such as self.i(self.j()) force readers to repeatedly inspect definitions.
Run 3
Code Structure: The class separates token generation, validation, hashing, and time handling into focused methods, but property declarations reference undefined getter/setter names, disrupting coherence. Nesting: Shallow nesting and early returns keep validation manageable; the loop-else requires some care. Clarity of intent: Docstrings and comments explain the password-reset mechanism, but single-letter method and variable names obscure roles and relationships. Code length: Generally concise, with useful documentation, although the multiline digest slice is unnecessarily awkward. Action granularity: Most statements perform one action, making individual operations easy to isolate. Reading flow: Validation follows a logical parse, verify, and expiry-check sequence, but opaque identifiers force readers to repeatedly trace calls and infer data meanings.