A similar issue has come up multiple times: the user
changes account's email address, enters a bad address
by mistake, and gets locked out of their account.
This commit adds an extra step in the "Change Email" flow:
* In "Account Settings", user clicks on [Change Email]
* User gets a prompt for a 6-digit confirmation code, which
has been sent to their old address. This is to prevent
account takeover when Eve sits down at a computer where Alice
is logged in.
* The user enters the confirmation code, and a "Change Email"
form loads.
* The user enters their new email address.
* (The new step!) Instead of changing the email right away,
we send a special login link to user's specified new address.
* (The new step, continued) The user clicks on the login link,
their account's email address gets updated, and they get
logged in.
The additional step makes sure the user can receive email
at their new address. If they cannot receive email there,
they cannot complete the "Change Email" procedure.
When testing with django==4.1a1, some tests were failing with
a message:
> ValueError: 'Check' instance needs to have a primary key
> value before this relationship can be used.
This commit fixes these failures, but there might be more
places to fix, that are not covered by tests yet.
I've run in the following problem a few times in tests:
* I create a model instance
* set its "created" field to a specific value
* I save the model instance
* I write testcase logic which relies on that specific "created" value
The testcase fails, because, with auto_now_add=True, Django
overwrites the created field. I can work around this by:
* Create and save a model instance
* Save it
* Set the created field to my desired value
* Save it again
But this is annoying to do, and annoying to troubleshoot
– it's easy to forget about the auto_now_add behaviour.
So I'm replacing auto_now_add=True with
default=django.utils.timezone.now.
The header format is:
Ping-Body-Limit: n
Where "n" is an integer number, the value of the PING_BODY_LIMIT
configuration setting.
Clients can use this header to decide how much POST data to send
in HTTP requests. If a client sends more than "n" bytes in the
request body, Healthchecks will store the first "n" bytes, and
ignore the rest.
The default value for PING_BODY_LIMIT is 10000 (10KB).
Accounts on self-hosted instances should have "unlimited" limits.
I had originally assumed 500 checks should be *enough for everybody*,
but in practice people do have accounts with 1000+ checks,
and may want to do scale testing with even more checks
(see #649). This commit raises the "unlimited" limits higher
to make it less likely users bump into them.
