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.
