52ae9a1f1c
All checks were successful
check / check (push) Successful in 2m0s
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