If we delete project by naively calling project.delete() then checks
can receive pings during the deletion, causing the deletion operation
to fail with an IntegrityError.
So instead do it like so:
* iterate over project's checks, call Check.lock_and_delete() on each
* in the end, call project.delete()
If AuthenticatedHttpRequest lives in the hc.lib.typealias
module then hc.lib.typealias imports User and Profile,
and so needs configured Django settings. Most of the stuff
in hc.lib is intended to work standalone, and not rely on Django.
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
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.
There is a specific limit of how many other users a given user
can invite in their projects (depends on the plan they are on).
When the limit is reached, the user cannot invite *new* users
in their projects, but they can still invite team members
from one project into another project. In other words, we count
the number of unique invited users, not the number of memberships.
There was an UI bug in the "Invite a Team Member" dialog. The
dialog has an editable "Email" text field. When an user has reached
the team limit, and they open the "Invite" dialog, they could
enter a new user's email address in the Email field and try to invite
them. The server would refuse to exceed the team limit and would
return a plain HTTP 403 page. This is of course confusing to the
end user.
The fix is to show "Email" as a text field only if the user has
not yet exceeded their team size. If they have, then show "Email"
as non-editable text.
Redirect unauthenticated users to the sign in page
instead. Rationale:
- The content on the welcome page is what often belongs
to a separate "marketing site". The marketing content
is of no use on self-hosted instances, which typically
have new signups disabled and are for internal use only
- (the real reason, let's be honest) a number of
self-hosted instances are accessible over the public
internet. Search engines index the nearly identical
landing pages and see them as duplicated content.
This fixes a security issue:
- attacker can crafts a redirect URL to an external site
- attacker gets victim to click on it
- victim logs in
- after login, Healthchecks redirects victim to the external site
The _allow_redirect function now additionally
requires the redirect URL is relative (has no scheme or domain).
If user has both WebAuthn and TOTP configured,
when logging in, they will be asked to choose between
"Use security keys" and "Use authenticator app".
The "Use authenticator app" is a link to a different
page (/accounts/login/two_factor/totp/). This commit makes
sure the ?next= query parameter is preserved when navigating
to that page.
For reference, the ?next= query parameter is the URL we should
redirect to after a successful login. Use case:
User is logged out. They click on a bookmarked "Check Details"
link. They get redirected to the login form. After
entering username & password and completing 2FA,
they get redirected to the "Check Details" page they
originally wanted to visit.
