Safari just doesn't recognize the Yubikey (macOS/iOS, NFC/USB, doesn't
matter) if display name is set to the empty string. Safari's long
description doesn't care to mention this requirement:
https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/
Tested on localhost with Safari macOS. Will test on iOS post deployment.
With the latest Docker update (27.0.3), it now warns about the "FROM" and "AS"
in the Dockerfile not matching. E.g. when building the server docker image:
> WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 1)
Safari just doesn't recognize the Yubikey (macOS/iOS, NFC/USB, doesn't matter)
if display name is set to the empty string. Safari's long description doesn't
care to mention this requirement:
https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/
Tested on localhost with Safari macOS. Will test on iOS post deployment.
Allow HTTP request body up to 4 MB. The default is 1 MB, which is too small for
face embeddings for photos with more than a couple of hundred faces.
Roughly, each face embedding is 4KB, but encrypting and base-64-ing the
embedding also has a 30% addition (just from one sample I saw), so this should
allow photos with ~700 faces to go through.
Ref:
- https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
The museum container depends on the postgres container being up and the DB being
ready to accept connections. To enforce this dependency, we use the healthcheck
attribute.
See: https://docs.docker.com/compose/startup-order/
The value of the healthcheck interval was set to 1s since the default (30s)
caused each `docker compose up` to require at least 30 seconds on each startup,
which was prohibitive. The downside is that the healthchecks continue to run
beyond the startup phase too, and for small VMs, this caused a lot of
unnecessary CPU usage.
Thankfully, now Docker has a new option for a different healthcheck during the
start phase:
> start interval is the time between health checks during the start period. This
option requires Docker Engine version 25.0 or later.
They were added in Docker compose 2.20.2, released an year ago (2023-07-19).
https://docs.docker.com/compose/release-notes/#2202
Despite all of our efforts, gmail insists on marking our verification emails to
new users as spam. We have already changed our mail delivery providers;
non-gmail users don't face this problem; and even for gmail, (a) existing Ente
users also get these mails correctly with SPF/DKIM/DMARC PASS, and (b)
non-verification emails get delivered (in the anecdotal reports we've received).
As an attempt at some voodoo, try changing the subject and content of the mail,
to try and rule out some faulty gmail classifier that uses the email body.
