Replace SQL string syntax with Rails range syntax for date filtering
in the ActivitySpike::Detector. This improves code readability and
follows Rails idioms.
Changed from:
.where("created_at >= ?", recent_period.seconds.ago)
To:
.where(created_at: recent_period.seconds.ago..)
This modernizes the codebase while maintaining the same functionality.
Simplifies the last_event method in ActivitySpike::Detector by using
the more idiomatic Rails pattern .order(:created_at).last instead of
.order(created_at: :desc).first. Both generate the same SQL query but
.last is more readable and conventional in Rails codebases.
* Allow Card#last_updated_at to be set
This is useful when doing an import from another system. I'm currently
working on a script to import our Github issues into Fizzy.
This is discussed in
https://github.com/basecamp/fizzy/pull/2056#discussion_r2609560246
* Add nil fallback and expand test coverage for last_active_at
Adds a safety fallback to Time.current if created_at is unexpectedly nil
during card creation.
Test coverage to verify:
* last_active_at defaults to created_at when not provided
* last_active_at can be updated via API on existing cards
* import workflow where last_active_at is restored after comments
* publishing doesn't overwrite explicit last_active_at values
---------
Co-authored-by: Jeremy Daer <jeremy@37signals.com>
* Add support to set `created_at`
Discussed in
https://github.com/basecamp/fizzy/pull/1766#issuecomment-3637846074,
this allows users to import cards from another system with entries from
the past. For instance I'm importing all our Github issues (including
the closed onces) to Fizzy.
* Iron out published state tracking
---------
Co-authored-by: Jeremy Daer <jeremy@37signals.com>
An append-only storage ledger replaces deadlock-prone synchronous
counter updates and drift-prone async updates.
All content storage (card images, card/comment/board description embeds)
is tracked. Account exports (which expire) and avatars are not tracked.
Storage is accounted for by Account and Board. Both consume the same
event stream independently: no bubble-up storage bumps triggering
deadlocks due to lock sequencing. Each calculates its own total from
the underlying ledger with independent cursors and materialization.
* Storage::Entry: Append-only ledger recording attach/detach/transfer
events with delta bytes. Single event stream indexed for both
Account and Board cursor queries.
* Storage::Total: Polymorphic snapshot cache with cursor (last_entry_id)
tracking which entries have been materialized.
* Storage::Totaled concern: Provides bytes_used (fast snapshot) and
bytes_used_exact (snapshot + pending) query modes, plus
materialize_storage! to roll up pending entries.
* Storage::Tracked concern: For models owning attachments (Card,
Comment, Board). Provides board_for_storage_tracking for models
where board is determined differently (Board returns self).
Handles board transfers by recording transfer_out/transfer_in entries.
* Storage::AttachmentTracking: Hooks ActiveStorage::Attachment lifecycle
to record attach/detach entries. Handles ActionText::RichText embeds
by traversing to the actual model. Snapshots context in before_destroy
to handle cascading deletes where parent record may be gone by
after_destroy_commit.
* MaterializeJob: Rolls up pending entries into snapshot. Concurrency
limited per owner to prevent duplicate work.
* ReconcileJob: On-demand reconciliation against actual attachment
storage for support/debugging. Compares ledger total to real bytes
from card images, card embeds, comment embeds, and board embeds.
Usage:
* account.bytes_used / board.bytes_used: fast, slightly stale bytesize
* account.bytes_used_exact / board.bytes_used_exact: real-time bytesize
* Storage::Entry: audit trail for debugging and point-in-time queries
This addresses a DoS vulnerability where the response might be massive
leading to OOM errors, as the response is read in full in memory by
default.
To prevent this, we need to read the body in chunks, checking the
size of the chunks we've read and raising if we go over a certain limit.
I've set the limit to 100 KB because the responses to these requests
should be fairly small or even empty, and we only care about the status
code in the end.
Adds verified? check to bundling_emails? to prevent notification emails
from being sent to users who have never authenticated. This closes the
spam vector where bad actors could create users for known email
addresses and trigger unwanted notifications by mentioning them.
Co-Authored-By: Claude <noreply@anthropic.com>
User are marked as verified after a join code is redeemed. The user is
redirected to Users::VerificationsController, either:
- after submitting a valid magic link code,
- or immediately after redeeming the join code (if they're already
authenticated with the correct identity)
Account owners are automatically verified when the account is
created (because they have already provided a magic link code at that
point).
This sets up for later commits that will backfill existing users and
require verification before sending notification emails.
Co-Authored-By: Claude <noreply@anthropic.com>
Process variants synchronously on attachment to close the window between
image upload and variant availability, guaranteeing that we won't have
lazy variant processing attempts in GET requests.
Tradeoff is that we do variant processing in upload requests, which is
actually desirable. We're working with images that should take
milliseconds to resize given that we'll already have the file on hand.
References https://github.com/rails/rails/pull/51951
Add SSRF protection for web push endpoints:
- Resolve endpoint IP once and pin it for connection
- Validate endpoints resolve to public IPs
- Whitelist permitted push service hosts
Add missing IP ranges to SsrfProtection:
- 100.64.0.0/10 (Carrier-grade NAT, RFC6598)
- 198.18.0.0/15 (Benchmark testing, RFC2544)
Note: link-local (169.254.0.0/16) is already covered by ip.link_local?
using the "standard" email regexp URI::MailTo::EMAIL_REGEXP. The form
field will validate this in the browser, but if bots are creating
identities, they can put whatever they want in here. So let's add some
protection against that.
The HtmlHelper regex was renamed here to avoid confusing Brakeman,
which does imprecise constant lookup and was confusing the two
constants, one of which uses `\A` and `\z` and the other does
not (intentionally).
ref: https://app.fizzy.do/5986089/cards/3276
Stanko K.R.