17370845950

Go中安全设置Cookie需同时启用HttpOnly、Secure和SameSite；使用gorilla/sessions时须正确配置Store与密钥，显式调用session.Save()，登出时须同步清理后端存储与Cookie。

Go标准库的http.Cookie怎么安全设置和读取

Go原生不带Session支持，但http.SetCookie和r.Cookie足够处理基础Cookie逻辑。关键不是“能不能设”，而是“设得对不对”。

常见错误是忽略HttpOnly、Secure和SameSite——这三者缺一就可能被XSS或CSRF利用。

• HttpOnly: true：阻止JS访问，防XSS窃取
• Secure: true：仅HTTPS传输，开发时若用HTTP需设为false（但上线必须true）
• SameSite: http.SameSiteLaxMode或http.SameSiteStrictMode：缓解CSRF，默认SameSite: ""等于不设，等同于开放攻击面

cookie := &http.Cookie{
    Name:     "session_id",
    Value:    "abc123",
    Path:     "/",
    HttpOnly: true,
    Secure:   true, // 生产环境强制开启
    SameSite: http.SameSiteLaxMode,
    MaxAge:   3600,
}
http.SetCookie(w, cookie)

用gorilla/sessions实现服务端Session管理

自己手写Session存储极易出错（比如并发写入、过期清理、密钥轮换）。社区事实标准是github.com/gorilla/sessions，它把加密、签名、存储解耦得很清楚。

核心是两个概念：Store（存哪）和Session（怎么用）。别直接操作Cookie值，始终走session.Values接口。

• 内存Store仅适合开发调试，cookiestore.NewCookieStore([]byte("your-32-byte-secret"))里的密钥必须≥32字节，否则启动报key must be 32 bytes long
• 生产环境务必换redisstore或postgresstore，避免重启丢Session
• 调用session.Save(r, w)才会真正写入响应头；漏掉这步，前端收不到新Cookie

store := cookiestore.NewCookieStore([]byte("12345678901234567890123456789012"))
session, _ := store.Get(r, "session-name")
session.Values["user_id"] = 123
session.Save(r, w) // 必须显式调用

为什么gorilla/sessions默认不自动过期Redis中的Session

它只管Cookie生命周期（MaxAge），不管后端存储。Redis里Session永不过期，除非你手动删或依赖Redis自身的EXPIRE策略。

典型陷阱：用户登出时只删了Cookie，但Redis里session_id还活着，别人拿到旧ID就能复用会话。

• 登出必须两步：清空session.Values + 调用session.Save() + 主动删除Redis中对应key
• 若用redisstore，构造Store时传入redis.Options{Addr: "...", Password: "", DB: 0}，再通过store.(*redisstore.RedisStore).Options().MaxAge控制TTL
• 更稳妥做法：所有Session写入Redis时都带EXPIRE，例如用redis.Client.SetEX(ctx, key, value, time.Hour)自行封装

自定义Session中间件要注意的并发与上下文传递

很多人写中间件把*sessions.Session塞进r.Context()，但没注意session.Save()需要http.ResponseWriter，而中间件里通常只有http.Handler的next.ServeHTTP(w, r)之后才真正写出响应。

结果就是：Session改了，但Save()没被执行，前端Cookie还是旧的。

• 不要在中间件里直接session.Save()——此时w可能已被包装（如gzip），导致Header写失败
• 正确做法：用context.WithValue(r.Context(), sessionKey, session)传下去，在业务Handler末尾统一session.Save(r, w)
• 如果用了chi或gin，优先用它们的Context机制，避免自己造WithValue嵌套过深

Session不是“设完就完”，从生成、传输、存储到销毁，每一步都有明确责任边界。最容易被跳过的，是登出时后端存储的清理和Cookie的彻底失效。