Checks can flip from "up" to "down" state as a result of changing
check's schedule. We don't want to send notifications when changing
schedule interactively in the web UI. So we update the `alert_after`
and `status` fields the same way as `sendalerts` would do. This is not
new, this was already being done.
With this change, we now additionally create Flip objects, recording
the fact that a check went down at such-and-such date. We fill the
"processed" field, to make sure sendalerts skips over these objects.
We need the Flip objects because otherwise the calculation
in Check.downtimes() could come out wrong (when a check later comes up,
we would have no record of when it went down).
The race scenario was as follows:
* Alice initiates email address change to bob@example.org
* a verification link is sent to bob@example.org
* separately, somebody creates a new account for bob@example.org
* Alice clicks on the verification link
At this point,
- if the database has an uniqueness constraint on auth_user.email,
Alice will receive a HTTP 500 error
- if there's no uniqueness constraint, the email change
will succeed and the system will have two accounts with the
same email address
The simple fix is to re-check the address availability just
before finalizing the email address change. Currently this is
not done in a transaction block, so the race condition still
exists in theory, but is much less likely to happen in practice.
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.
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).
