Why remove:
* For self-hosters, payment-related features are unused and dead weight
* For SaaS (any would-be Healthchecks.io competitors), the existing
payment handling logic is not very useful either, as it would need to
be heavily modified to match their business model, pricing, chosen
payment gateway
* For the hosted service (Healthchecks.io), the up-to-date billing code
lives in a private fork of this repo. Maintenance is easier if this
repo does not have an older, diverging version of the same
functionality
A few payment-related bits are staying at least for time being:
* the "USE_PAYMENTS" setting
* the hc.payments.models.Subscription model
* tiny stubs for the "Pricing" and "Billing" pages
They are used in various places in the code and templates,
and I think ripping them out in one go would be too disruptive.
In Project admin, when listing project members, for single-member
projects the owner's email address was being displayed
unescaped. This allowed unescaped amperstand and quote characters
to appear in HTML output.
The "auto-login" cookie is a part of a work-around for
some email clients automatically clicking links in emails:
- when sending an one-time sign-in link, server also sends the
"auto-login" cookie to the client
- when end user clicks on the sign-in link, the server checks
if client's request contains the "auto-login" cookie
- if the "auto-login" cookie is present, log the user in
- if the "auto-login" cookie is absent, serve a HTTP POST form
with a submit button. The user must click the button to log in.
This commit fixes attributes on the "auto-login" cookie:
- it sets SameSite=Lax
- it sets Secure=true if SESSION_COOKIE_SECURE=True
* Added duration to ping details. This is useful on a device with a small screen, since the duration cannot be seen in the main view so now one can see it in the ping's details.
* Changed terms across the board from "delta" to "duration"
* timedelta is now consistently imported as "td" across the entire project (even in Django generated migration files)
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.
