user 52ae9a1f1c fix: detect TLS per-request in CSRF middleware to fix login ...

The CSRF middleware previously tied its PlaintextHTTPRequest wrapping
and cookie Secure flag to the IsDev() environment check. This meant
production mode always assumed HTTPS, which broke login in two common
deployment scenarios:

1. Production behind a TLS-terminating reverse proxy: gorilla/csrf
   assumed HTTPS but r.TLS was nil, causing Origin/Referer scheme
   mismatches and 'referer not supplied' errors.

2. Production over direct HTTP (testing/development with prod config):
   the Secure cookie flag prevented the browser from sending the CSRF
   cookie back on POST, causing 'CSRF token invalid' errors.

The fix detects the actual transport protocol per-request using r.TLS
(direct TLS) and the X-Forwarded-Proto header (reverse proxy). Two
gorilla/csrf instances are maintained — one with Secure cookies for TLS
and one without for plaintext — since the csrf.Secure option is set at
creation time. Both instances share the same signing key, so cookies
are interchangeable between them.

Behavior after fix:
- Direct TLS: Secure cookies, strict Origin/Referer checks
- Behind TLS proxy (X-Forwarded-Proto: https): same as direct TLS
- Plaintext HTTP: non-Secure cookies, relaxed Origin/Referer checks
  (csrf.PlaintextHTTPRequest), token validation still enforced

Closes #53

2026-03-17 05:28:54 -07:00

12 KiB

Raw Blame History

View Raw