photoplaces/obsidian_data/Photoplaces_data/atomic-cookie-secure-via-protocol.md

Secure-флаг куки: определение через протокол запроса, а не APP_ENV

Контекст: На тестовом сервере (192.168.88.128) Caddy работает через HTTP (порт 80), но APP_ENV=production. Cookie refresh_token устанавливалась с Secure: true, из-за чего браузер отклонял её на HTTP-соединении → рефреш токен терялся при перезагрузке страницы → деавторизация.

Суть: Secure-флаг теперь вычисляется динамически:

• r.TLS != nil (прямое HTTPS-соединение)
• X-Forwarded-Proto: https (за прокси — Caddy)

Что изменилось:

• helpers.go: добавлена isSecure(r *http.Request) bool; setRefreshTokenCookie принимает *http.Request вместо bool
• auth.go, setup.go: убран мёртвый isProd, вызовы передают r
• Caddyfile: добавлен header_up X-Forwarded-Proto {scheme} в прокси на backend
• main.go: NewAuthHandler и NewSetupHandler больше не принимают appEnv

Связанные заметки: [[atomic-api-contract-refresh-cookie]], [[atomic-global-appenv-package-var]] Источник: Баг на тестовом сервере — деавторизация после нескольких F5