SeedRetrieveCreate printed every submitted password to stdout, so it
ended up in container and server logs. The reset view logged complete
reset URLs at debug level, and those work as credentials until used.
The highest uidNumber was cached in dal/ldap_max_uid_file. That breaks
with more than one replica and is lost on every container restart. The
uniqueness check behind it searched base '' (the root DSE), which
OpenLDAP never matches, so nothing caught a stale file. The error path
also referenced a setting that does not exist.
Now a paged search over ENTIRE_SEARCH_BASE finds the highest uidNumber
on each activation. Numbering is unchanged: the next number is above
both LDAP_DEFAULT_START_UID and every existing uidNumber.
LDAP_MAX_UID_FILE_PATH is no longer used.
Registration only collided inside ou=customers, so a staff username
from ou=users could be registered again as a customer, creating two
accounts with the same uid. Check the whole tree (ENTIRE_SEARCH_BASE)
on the register form, in the create API, and again at activation in
case the name was taken in between.
The activation link carried base64-encoded username, password, names
and email, so plaintext passwords ended up in mail archives, browser
history and proxy logs.
Registration now hashes the password to {SSHA} immediately and stores
it in a new PendingRegistration table (migration 0002). The emailed
link is /activate/<token>/ with a random token only, and activation
writes the stored hash into LDAP. Pending entries expire after 24h,
like reset tokens. This also drops the PseudoUser/token-generator
workaround.
Links in emails sent before deployment stop working; those users must
register again.
ResetRequest.post took the username from a hidden form field and
changed that user's password without checking any token, so anyone
could take over any account with a single POST to /reset/.
Opening a valid reset link now stores the verified username in the
session (valid for one hour, cleared after use). The POST only acts on
that user and ignores the form field. Reset tokens now come from
secrets.token_urlsafe, and malformed links return 404 instead of 500.
The uid was formatted straight into search filters, so a password
reset for user '*' matched and changed the first entry in the tree
(staff accounts included). Escape filter values with
escape_filter_chars and DN values with escape_rdn.
Also fix the username pattern: [a-z|0-9|\-|_] allowed '|'.
Restore root requirements.txt pinned to what production runs
(Django 2.2, last patch 2.2.28) so the upgrade starts from a
reproducible baseline. Restore logs/.keep; the logging config fails
on a fresh clone without the directory.
The tests drive every view over HTTP against the real test LDAP:
login, registration and activation, data and password changes,
password reset, account deletion, the create API and OTP seeds.
Known bugs are recorded as expected failures:
- password reset POST changes any user's password without a token
- LDAP filter injection in reset (user='*' hits the first entry)
- activation link carries the base64-encoded password
- a username from ou=users can be registered again under ou=customers
