Send a --cookie login under both session cookie names

Merged
JE
20h ago
+18-9

What

hey auth login --cookie now sends the stored value as Cookie: __Host-session_token=<v>; session_token=<v> instead of only session_token=<v>. REST and Action Cable both go through Manager.authenticateRequest, so both pick it up.

Why

basecamp/haystack#8993 moves browser sign-ins to a __Host-session_token cookie. Rails binds a signed cookie's signature to its name, so after that ships, a value copied from a newly signed-in browser fails if hey-cli sends it as session_token.

With both names, it works either way, against #8993 and against HEY today:

  • #8993's server: it reads __Host-session_token first (Authenticate::ByCookie#find_session_by_session_cookie). A value signed for the other name verifies as nil there, so it falls back to session_token.
  • Doubled-cookie rule: session_token still appears exactly once, so #8993's rule that signs out a request carrying it twice doesn't trigger.
  • HEY today: it reads only session_token and ignores the other name.

Credentials already stored need no migration, and nothing has to ship in step with #8993.

The --cookie help now names both cookies. The smoke tests are unchanged. They sign in against http://app.hey.localhost:3003, where the server still sets session_token because the request isn't over TLS. Pointed at an HTTPS server, they'd need to read and plant __Host-session_token.

Tests

make check passes. The cookie-header expectations in internal/auth, internal/cable and internal/cmd now expect both names.

Summary by cubic

Makes hey auth login --cookie send the stored value as both __Host-session_token and session_token cookies instead of only sending session_token. This keeps the CLI working once browser sign-ins move to __Host-session_token (basecamp/haystack#8993) and continues to work against HEY today, with no migration needed for stored credentials.

Why this works

  • Rails binds a signed cookie's value to its name, so a value copied from one cookie verifies as nil under the other; the server reads __Host-session_token first, falls back to session_token, and sees session_token exactly once, so the double-cookie sign-out rule doesn't trigger.
  • REST and Action Cable requests both authenticate through Manager.authenticateRequest, so both pick up the doubled header.
  • The --cookie help text now names both cookies, and the cookie-header expectations in tests were updated to match.