The bug: the Log page would sometimes show a number of "zombie"
notifications at the very end: notifications that should not be
shown to the user, but have not yet been garbage-collected.
The fix: when preparing the created__gte filter value for the
notification query, make sure the filter value is not lower than the
timestamp of the oldest visible ping.
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 code in Check.ping() updates a Check object, then
creates a Ping object. There's a possible race condition
where the "sendalerts" command sees# the updated Check object
before the Ping object is created. This is especially likely
when offloading ping bodies to S3, because Ping gets created
*after* the upload completes, which can take some time.
To avoid this, put both operations inside a transaction,
but keep the S3 upload *outside* the transaction--uploads
can hang, and we want to avoid long transactions.
If every fetched ping is a success event, and has an unique
run ID, then we cannot determine the duration just from the
fetched data, and must fall back to Ping.duration(). This
would generate a SQL query per displayed ping.
The solution is to count how many times we would need to use
the fallback, and if it goes above some threshold (currently,
10 times), then disable duration display altogether.
