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
