fix: scope session cookie name per instance to prevent CSRF 422s#364
Merged
Conversation
Multiple Hivemind instances on one host (via `hivemind new`) run on different localhost ports. Browsers share cookies across ports for the same host, and every instance used the default session cookie name `_hivemind_session`. Combined with each instance having its own SECRET_KEY_BASE, the instances overwrote each other's session cookie, so the authenticity token in a rendered form no longer matched the cookie on POST — Devise sign-in failed with "Can't verify CSRF token authenticity" (HTTP 422). Key the session cookie on COMPOSE_PROJECT_NAME (unique per instance, already passed into the container via env_file). The primary keeps `_hivemind_session` via the default fallback, so existing sessions are not invalidated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A second Hivemind instance created via
hivemind new(#363) cannot sign in. Devise returns HTTP 422 "Can't verify CSRF token authenticity" onPOST /users/sign_in.Root cause
It's a session-cookie collision, not a real CSRF attack:
config/initializers/session_store.rb, so Rails derived the default session key from the app module (module Hivemind) →_hivemind_session. Both the primary andhivemind newinstances used that exact name.SECRET_KEY_BASEper instance.bin/hivemindcorrectly generates fresh secrets for each new instance, so the two instances sign/encrypt their session cookies with different keys.localhost:8080(primary) andlocalhost:8081(new instance) share one cookie jar, so both write a cookie literally named_hivemind_sessionand overwrite each other.Result: loading one instance stomps the other's session cookie. On
POST, the form's authenticity token no longer matches the (now-foreign, undecryptable) cookie → 422. This is why it's always the most recently loaded instance that fails.Fix
Add
config/initializers/session_store.rbthat keys the session cookie onCOMPOSE_PROJECT_NAME, which is already unique per instance (hivemindvshivemind-<name>) and passed into the Rails container viaenv_file: .env:The primary keeps
_hivemind_sessionvia the default fallback, so existing sessions are not invalidated. New instances get_hivemind-<name>_session, isolating cookies even on a sharedlocalhost.Testing
_hivemind_sessioncookie name (Action Cable, mobile views, etc. all read from the session abstraction).hivemind newinstance in the same browser — both now hold independent sessions.🤖 Generated with Claude Code