* robots.txt: "Please, don't come in." If a page is directly linked, the
URL can still appear in search results, though.
* X-Robots-Tag: "If you're here, forget what you saw." Works even if the
crawler ignores robots.txt or reaches a page via external link. Can
remove already-indexed pages.
* Public boards may not be indexed. They're meant for "anyone with the
link" private sharing, not worldwide publishing.
- Adds a button in Account Settings where you can request a ZIP export of your
Fizzy data
- Export files are created in the background. When ready, a link to
download them is sent to the requester.
- Exports expire after 24 hours. And are limited to 10 per day.
Previously if someone started signing in on their phone, but finished it on their laptop, they'd end up on the menu screen with no account. Bu tracking the purpose of a Magic Link we can always direct the user to sign up if they requested a magic link through sign up. This also makes the logic for changing the copy in the email more robust.
This is a great, solid alternative to CSRF tokens for CSRF protection
when we aren't worried about older browsers or other kind of actors
doing modifying requests in our app, and could be a good test for future
upstreaming to Rails (although there we'd need to continue using CSRF
tokens or at least letting people opt out manually).
Let's start checking the header and reporting on it when CSRF fails or
when it doesn't match the other checks Rails does, and then promote this
to be the only way to defend from CSRF.
Instead of writer pinning, we'll track the last transaction ID of each
write in the session. Then on each read we'll wait for the replica to
report that this transaction is available.
If it doesn't become available within a reasonable timeout, we'll
proceed anyway, and accept the possibility of a stale read.
The hope here is that most of the time, the replica is caught up in the
time between a write request and the following read request. If it's
not, we now have a little tolerance to wait for it, which hopefully
proves enough to stale reads are not encountered in normal use.
We also disable the writer affinity opt-out mechanism that we had
before, since we will no longer be using writer affinity at the load
balancer.
User flows when editing a card look like:
- Click "Edit" → the closure buttons are replaced by "Save changes"
- Submit card form → Saves and restores closure buttons
- Press ESC while editing → Cancels and restores closure buttons
Also, renamed for clarity:
- _title.html.erb → _content.html.erb
Co-Authored-By: Claude <noreply@anthropic.com>
- redirect avatar image requests to the rails_blob_url, instead of
streaming them through the web app
- use a thumbnail variant for avatar images
- only put avatar initials behind the stale? check (not the image
redirect, which would result in browsers rendering broken images when
an avatar is changed, until max-age expires)
Locally, having stale_while_revalidate works great, but in production when we are behind CloudFlare, this results in an old image being shown after you upload a new one
See: https://app.fizzy.do/5986089/cards/2978
Stanko K.R.