On successful submission of a password reset request, an email is sent
to the accounts known to the system. If sending this email fails (due to
email backend misconfiguration, service provider outage, network issues,
etc.), an attacker might exploit this by detecting which password reset
requests succeed and which ones generate a 500 error response.
Thanks to Thibaut Spriet for the report, and to Mariusz Felisiak, Adam
Johnson, and Sarah Boyce for the reviews.
Refs #34429: Following the implementation allowing the setting of
unusable passwords via the admin site, the `BaseUserCreationForm` and
`UserCreationForm` were extended to include a new field for choosing
whether password-based authentication for the new user should be enabled
or disabled at creation time.
Given that these forms are designed to be extended when implementing
custom user models, this branch ensures that this new field is moved to
a new, admin-dedicated, user creation form `AdminUserCreationForm`.
Regression in e626716c28.
Thanks Simon Willison for the report, Fabian Braun and Sarah Boyce for
the review.
This branch migrates setuptools configuration from setup.py/setup.cfg to
pyproject.toml. In order to ensure that the generated binary files have
consistent casing (both the tarball and the wheel), setuptools version
is limited to ">=61.0.0,<69.3.0".
Configuration for flake8 was moved to a dedicated .flake8 file since
it cannot be configured via pyproject.toml.
Also, __pycache__ exclusion was removed from MANIFEST and the
extras/Makefile was replaced with a simpler build command.
Co-authored-by: Nick Pope <nick@nickpope.me.uk>
Co-authored-by: Adam Johnson <me@adamj.eu>
Co-authored-by: Mehmet İnce <mehmet@mehmetince.net>
Co-authored-by: Sarah Boyce <42296566+sarahboyce@users.noreply.github.com>
Prior to this change, squashmigrations would use a [yN] prompt to ask
for user confirmation. A slash was added between the yes/no options
to make it consistent with other commands that print similar prompts.
The timezone documentation for Postgres mentions the behavior of
time zone conversion, but links to the wrong setting that controls the
behavior.
Postgres will not return datetimes in the time zone set by the
TIME_ZONE setting, but rather the time zone of the database connection,
which is defined by DATABASES.TIME_ZONE setting falling back to UTC.
This corrects the link in the documentation and adds note that there
are two distinct TIME_ZONE settings and the one most are familiar with
is not considered for PostgreSQL time zone conversion.
