Cookie и сессии

HTTP по спецификации не помнит ничего: каждый запрос живёт сам по себе, и сервер в принципе не обязан связывать два запроса от одного браузера. Для статических страниц это нормально, но трекер, который после логина снова считает вас гостем, никому не нужен. gin cookie — это ровно две обёртки над стандартной библиотекой: c.SetCookie ставит заголовок Set-Cookie в ответе, c.Cookie читает заголовок Cookie из запроса. Механика RFC 6265 простая: сервер в ответе говорит браузеру «запомни пару goma=1 и возвращай мне её»; браузер сохраняет и с каждым запросом к этому хосту отправляет её обратно в заголовке Cookie — сервер снова «узнаёт» клиента. Всё состояние при этом лежит у клиента: cookie — не память сервера, а памятка, которую он выдал гостю. Отсюда два следствия, которые определяют весь урок. Первое: cookie можно читать и подделывать — пользователь открывает DevTools и видит значения целиком, поэтому в чистой cookie не хранят ничего секретного. Второе: cookie ограничена — примерно 4 КиБ на пару и лимиты на домен, куда словарь задач не упакуешь. Для простых вещей — «пользователь закрыл онбординг», «выбрал тёмную тему», «последний раз был вот тут» — чистой cookie хватает. Для полноценной аутентификации поверх cookie строят сессии: словарь живёт на сервере, а в cookie едут только ссылка на него — идентификатор или подписанный пакет. Связку «простая cookie — c.SetCookie», «сессия — middleware из gin-contrib» и разберём в этом порядке: сначала механика значения, потом слой над ней. Хендлер возьмём из арсенала трекера: счётчик визитов — минимальный пример «узнавания» клиента без единой строчки серверного состояния.

c.SetCookie(name, value, maxAge, path, domain, secure, httpOnly) — обёртка над http.SetCookie, и все семь аргументов превращаются в поля структуры http.Cookie. Имя и значение — ASCII-строки; значение — любое слово клиента, так что сериализуйте и проверяйте его сами, а не верьте, что там окажется то, что вы положили. maxAge — секунды жизни, и здесь три режима: положительное число — «живи столько-то секунд» (Max-Age=3600 — час); ноль — заголовок Max-Age вообще не ставится, cookie становится сессионной и живёт до закрытия браузера; отрицательное число — Max-Age=0, cookie приказывает браузеру немедленно удалить старое значение. Это самый недооценённый аргумент: logout, который хочет «стереть» cookie, обязан повторить её Set-Cookie с тем же именем, path и domain и отрицательным maxAge — иначе пара продолжит ездить. path — префикс URL, на который браузер согласен отправлять cookie: «/» едут на все маршруты, «/api» — только на маршруты, начинающиеся с этого префикса; более узкий path — более узкий размах, но помните, что несовпадающий path не удаляет cookie, а создаёт вторую. domain — по умолчанию cookie привязана к хосту, который её выдал, и поддомены её не видят; указание domain=.example.com разделяет её на все поддомены — не включайте без причины. secure — отправлять только по HTTPS; httpOnly — запретить JavaScript доступ через document.cookie. Важная дыра gin-обёртки: у c.SetCookie нет аргументов для SameSite и Expires — их ставит только полная форма: http.SetCookie(c.Writer, &http.Cookie{Name: "goma", Value: "1", MaxAge: 3600, Path: "/", HttpOnly: true, Secure: true, SameSite: http.SameSiteLaxMode}). c.Writer — это http.ResponseWriter из урока про middleware, и http.SetCookie просто дописывает заголовок в его карту. Пользуйтесь короткой формой, пока хватает её семи аргументов, и полной — когда дошли до SameSite.

Три флага — три линии обороны, и включать их нужно осознанно, а не «когда-нибудь в проде». HttpOnly запрещает JavaScript читать cookie через document.cookie. Зачем: если XSS просочился сквозь экранирование из урока про шаблоны — одна забытая {{ .Name | safeHTML }} — скрипт атакующего выполняется на вашей странице и первым делом тянет document.cookie наружу. HttpOnly не чинит XSS, но выжигает самую жирную награду: украденную сессию нельзя переиспользовать с чужой машины. secure=true — браузер не отправит cookie по незащищённому http: без него первый же открытый Wi-Fi превратит cookie в подарок попутчику, слушающему трафик. В разработке на http://localhost флаг придётся временно ставить false — или поднимать локальный TLS. SameSite — защита от того, чтобы браузер приложил вашу cookie к запросам с чужих сайтов; деталей про CSRF-сценарий — в уроке про CORS и безопасность, здесь фиксируем режимы: http.SameSiteLaxMode — cookie едет только в переходах верхнего уровня по GET, то есть по обычной ссылке с чужого сайта cookie приложится, а POST-формой злоумышленника — нет; Strict — вообще не едет с чужих сайтов, вплоть до того, что переход по ссылке из мессенджера придёт на сайт «незалогиненным»; None — едет всегда, но требует secure=true и нужен только для честного кросс-сайтового встраивания. Современные браузеры по умолчанию ведут себя как Lax. Отдельное правило гигиены: Path и Domain — про минимальный размах. Cookie для админки не обязана летать на /api, а для статического CDN — вообще не нужна: чем уже область видимости, тем меньше поверхностей. И последнее: в cookie не кладут пароли, токены карт и персональные данные — слово клиента читается как открытая книга, вплоть до того, что пользователь вправе его отредактировать.

Чистая cookie хорошо возит флаги и плохо — аутентификацию: значение читается, редактируется и ограничено 4 КиБ. сессии gin решают это надстройкой: словарь «ключ-значение» живёт на сервере (или в подписанной cookie — о хранилищах ниже), а браузеру достаётся либо непрозрачный идентификатор, либо упакованный пакет. Механика слоя — пакет github.com/gin-contrib/sessions: go get github.com/gin-contrib/sessions — и два шага. Первый: при старте создайте хранилище и повесьте middleware: store := cookie.NewStore([]byte(os.Getenv("SESSION_SECRET"))); r.Use(sessions.Sessions("goma", store)) — «goma» здесь имя cookie, в которой сессия будет жить, одно звено на всё приложение, ставится до маршрутов, как и все звенья из урока про кастомные middleware. Второй: в хендлере session := sessions.Default(c) — интерфейс с четырьмя методами словаря: session.Get("user") возвращает any и nil, если ключа нет; session.Set("user", username) кладёт значение; session.Delete и session.Clear вычищают ключ или всю сессию. Критичное, что забывают все: изменения копятся в сессии в памяти запроса и НЕ попадают в ответ автоматически — их публикует session.Save(). Забыли Save — cookie уйдёт без изменений, пользователь вроде «залогинился», но при следующем запросе снова гость; ошибки при этом нет, баг тихий, и живёт он до первого прогона руками. Хранилище настраивается флагами: store.Options(sessions.Options{MaxAge: 3600, Path: "/", HttpOnly: true, Secure: false, SameSite: http.SameSiteLaxMode}) — те же поля http.Cookie, что мы разбирали выше, только применяются ко всем сессиям этого store. Обратите внимание: имя cookie «goma» и секрет SESSION_SECRET — это всё, что злоумышленник узнаёт о вашей сессии; словарь остаётся на сервере, и в этом весь смысл слоя.

cookie.NewStore([]byte(secret)) — самое неожиданное хранилище сессий: словарь не живёт на сервере вовсе, а сериализуется, кодируется base64 и кладётся прямо в cookie у клиента. Отсюда парадоксальное свойство: сервер stateless — рестарт процесса не стирает ни одной сессии, кластер из десяти узлов не нуждается в общем redis, а нагрузка на память нулевая. Но клиент держит сессию в руках — что мешает ему дописать себе role: "admin"? Мешает подпись. cookie.NewStore принимает до двух ключей: hashKey и blockKey. hashKey обязателен и должен быть 32 или 64 байта — им считается HMAC-SHA256 (или SHA-512) над содержимым; в cookie попадает значение и подпись через вертикальную черту, а на каждом запросе middleware пересчитывает HMAC и сравнивает. Байт поменян — подпись не сходится — cookie отбрасывается, сессия становится пустой: подделка отсечена. Именно поэтому ключ из os.Getenv, а не литерал в коде: секрет в git — это подписанные сессии любого, кто скачал репозиторий. blockKey — необязательный второй ключ длиной 16, 24 или 32 байта: включает AES-шифрование содержимого. Без него база64-строку видно целиком: скормите её любому декодеру — получите JSON сессии с username и прочим. Подпись гарантирует целостность, но не конфиденциальность, и это главный вывод про cookie-хранилище: не кладите в сессию ничего, что не готовы показать пользователю, — идентификатор пользователя, имя, язык, тему — можно; роль, секреты, номер карты — нельзя, роли и секреты проверяйте на сервере по идентификатору. Отдельная гигиена — ротация: смена hashKey делает все существующие сессии невалидными, и все пользователи разом разлогинятся; если ключ заподозрили в утечке, это фича, а не баг, но плановую ротацию лучше не показывать продам.

sessions — интерфейс над хранилищами, и от выбора хранилища зависит, где живут данные и что переживает аварии. cookie.NewStore — данные у клиента, подписанные HMAC; сервер ни о чём не помнит, рестарт и горизонтальное масштабирование бесплатны, лимит — те самые 4 КиБ и правило «ничего секретного». redis.NewStore(10, "tcp", "localhost:6379", "", "") — сессии живут в redis, а в cookie у клиента только непрозрачный идентификатор; размер словаря перестаёт волновать, секретные поля — тоже, и появляется возможность выкинуть сессию принудительно: удалили ключ в redis — пользователь разлогинен, даже если cookie жива. Цена — зависимость от redis и общий узел для всех реплик: классическая замена stateless на stateful. memstore из того же пакета хранит сессии в памяти процесса — идеально для тестов и мгновенно умирает при рестарте, в прод не тащить. Выбор сводится к трём вопросам. Сколько данных? Пара строк — cookie-хранилище, сотни килобайт или корзина покупок — redis. Сколько узлов? Один — cookie-хранилище всё ещё ок, кластер — cookie-хранилище тоже ок, но только пока данные безобидные; redis — когда нужен единый источник правды. Нужен ли мгновенный logout и бан? С cookie-хранилищем «отозвать сессию» невозможно — она у клиента; с redis — один DEL. Для нашего трекера cookie-хранилище честно тянет первые месяцы, а дальше, когда появятся корзины, права и «выйти на всех устройствах», переезд на redis — замена одной строки создания store, весь код хендлеров не меняется: interface Store у пакетов один и тот же.

У сессий есть спецрежим для одноразовых значений — флеш-сообщения. session.AddFlash("Задача сохранена") кладёт значение, которое живёт ровно до первого чтения: session.Flashes() возвращает слайс всех накопленных флешей и очищает их, так что при следующем запросе список пуст. Классический сценарий — Post-Redirect-Get: пользователь отправляет форму POST-ом, и просто «ответить 200» значит обречь его на повторную отправку формы по F5; правильный флоу — обработать POST, положить в сессию «что получилось», ответить редиректом на страницу списка и уже там показать сообщение. В трекере это выглядит так: POST /todos валидирует TodoInput, при ошибке AddFlash("Проверьте поля") и redirect 303 на /, при успехе AddFlash("Задача добавлена") и тот же redirect; страница / читает Flashes и рисует сообщение над списком. Не забудьте Save и после чтения флешей — очистка тоже изменение сессии. Второй слой сценариев — прочие одноразовые флаги: «вы уже видели онбординг», «показать предупреждение о входе с нового устройства», закрытие диалогов. Третий слой — идентификация владельца задач: звено из урока про кастомные middleware достаёт session.Get("user"), кладёт в c.Set("user", ...), и все хендлеры ниже читают владельца из контекста, фильтруя задачи. Это ровно та архитектура, на которой в следующем уроке построят JWT-гвард — только источником идентичности станет подписанный токен, а не словарь на сервере. Заметьте прогресс: в четвёртом уроке трекер принимал задачи от анонимов, в этом — знает, кто их прислал, и не покажет чужой список.

Cookie отлаживается curl-ом лучше, чем любым фреймворком, — через cookie jar. curl -c jar.txt -X POST -d "username=om" localhost:8080/login — флаг -c сохраняет присланное Set-Cookie в файл; откройте jar.txt: там имя, значение, домен, path и срок. curl -b jar.txt localhost:8080/profile — флаг -b отправляет сохранённое обратно, и профиль отвечает вашим пользователем. Так прогоняется весь флоу: логин, профиль, logout, повторный профиль с 401 — без браузера и без фантазий о том, «что там сервер подумал». В браузере путь тот же: DevTools, вкладка Network — смотрите заголовки Set-Cookie ответа и Cookie запроса, вкладка Application — таблица всех cookies с флагами HttpOnly, Secure, SameSite, сроком и размером. Три частые грабли из практики. Первая: cookie не приходит на нужный маршрут — проверьте path: логин поставил Path=/login, а профиль ждёт на / — браузер в этот path не заходит; удаляйте cookie тем же path, каким ставили, иначе получите вторую с тем же именем. Вторая: значение рассыпалось на мусор — cookie любит запятые и пробелы: кодируйте значение (url-кодирование, base64), прежде чем класть. Третья: «работает в Postman, не работает в браузере» — почти всегда SameSite или Secure: Postman не браузер, он cookie прикладывает всегда, а браузер уважает флаги. И помните из урока про логирование: gin.Logger пишет только статус и время — cookie в логи не попадают, и слава богу: в сессии живёт аутентификация, а логи читает вся команда.