Donal McBreen
8a6e4290d8
* Derive message DOM ids from the server id, not client_message_id A message's DOM id was derived from the browser-chosen client_message_id via a Message#to_key override, so dom_id(message) was "message_<client_message_id>". Turbo's append de-dups by DOM id, so a room member who posted a message reusing a victim's client_message_id displaced the victim's message element in every connected member's live view; editing the attacker's own message then broadcast onto the victim's presentation id. Drop the to_key override so every message DOM id and broadcast target derives from the record's primary key. Two distinct records can no longer share a DOM id regardless of stored client_message_id, so the collision is impossible with no data migration and no uniqueness constraint. to_param and the fragment cache key already used the primary key, so message URLs and per-message cache entries are unchanged. The composer's optimistic pending message still uses client_message_id as its placeholder DOM id, which no longer matches the server broadcast's PK-based id. Reconcile instead by rendering data-client-message-id on the real message and having the messages controller drop the matching pending placeholder on connect. Only client-side placeholders (data-pending-message) are removed, so a message another member posts reusing the same client_message_id can never displace a real one through the reconciliation path either. Also point the boost broadcast target at the PK-based dom_id(message, :boosts) to match the rebuilt container id. GHSA-3v99-4vxh-xg84 * Bust cached message fragments rendered with client_message_id DOM ids The message fragment cache keys on the record and the template digest, and removing the to_key override changes neither. Fragments cached by an earlier release would keep their message_<client_message_id> ids, so edit, delete and boost broadcasts, which now target primary-key ids, would miss those messages in other members' live views until the cache entry expired. * Locate messages by record id in the client_message_id collision tests Assert on data-message-id rather than the new primary-key DOM ids, so the tests describe the behavior instead of the fix and fail on the vulnerable code for the real reason. Edit the attacker's message to new text and wait for it to arrive, so the edit path is exercised rather than passing vacuously. Add a request test that two messages sharing a client_message_id render as distinct elements. --------- Co-authored-by: Jeremy Daer <jeremy@37signals.com>
Campfire
Campfire is a web-based chat application. It supports many of the features you'd expect, including:
- Multiple rooms, with access controls
- Direct messages
- File attachments with previews
- Search
- Notifications (via Web Push)
- @mentions
- API, with support for bot integrations
Running your own Campfire instance
Campfire's Docker image contains everything needed for a fully-functional,
single-machine deployment. This includes the web app, background jobs, caching,
file serving, and SSL. You can use our pre-built image at
ghcr.io/basecamp/once-campfire:latest, or build your own from this repo.
Deploying with ONCE
The easiest way to self-host Campfire is with ONCE. It will guide you through the initial set up and then keep your instance up to date automatically.
If you don't already have once installed, run this on the machine you want to run Campfire on:
curl https://get.once.com | sh
once will launch as soon as the install is finished.
Choose Campfire from the list of applications, follow the instructions, and ONCE will take care of the rest.
If you prefer the command line to the dashboard, you can deploy directly:
once deploy ghcr.io/basecamp/once-campfire --host chat.example.com
Deploying with Docker
If you'd rather run the Docker image yourself, you can read more about that in the self-hosting guide.
Tip
When you start Campfire for the first time, you'll be guided through a wizard to create an admin account. The email address that you enter for the admin account will be visible on the sign-in page, it's there so that people have someone to contact if they need help with their account. If that bothers you, put in any email address you want and create yourself a new admin account.
Other implementations
Campfire also has implementations in Django, Laravel, Express, Elixir, Go and Rust:
| HTTP workload (requests/sec) | Rails | Django | Laravel | Express | Elixir | Go | Rust |
|---|---|---|---|---|---|---|---|
| Room page | 241 | 170 | 164 | 559 | 722 | 3,860 | 36,260 |
| Messages page | 413 | 196 | 175 | 777 | 1,053 | 5,573 | 40,872 |
| Sidebar | 552 | 615 | 715 | 4,125 | 1,275 | 19,753 | 34,672 |
| Search | 435 | 315 | 305 | 1,294 | 1,156 | 7,053 | 33,299 |
| Post a message | 273 | 154 | 137 | 256 | 801 | 4,767 | 6,896 |
Measured with 16 concurrent clients on an AMD Ryzen AI MAX+ 395, with four hardware threads allocated to each app.
Development
You are welcome - and encouraged - to modify Campfire to your liking. Please see our development guide for how to get Campfire set up for local development.
Security
See SECURITY.md for how to report a vulnerability and a description of our trust model.