17370845950

martini 应用中使用 `martini-contrib/sessions` 时，session 数据在请求间丢失，通常因中间件执行顺序不当或响应未正确提交 cookie 导致；本文详解正确配置 cookie store、确保中间件顺序、避免提前终止请求等关键修复步骤。

在 Martini 框架中，Session 跨请求失效是一个常见但易被忽视的问题。从你提供的代码来看，逻辑本身（如 session.Set() 和 session.Get()）并无语法错误，但实际运行中 /session 接口返回空结构体，说明 Session 数据未能持久化到后续请求——根本原因几乎总是 HTTP 响应未携带有效的 Set-Cookie 头，导致浏览器无法保存或回传 session ID。

✅ 正确的 Session 中间件使用前提

Martini 的 sessions.Sessions() 是一个 全局中间件（Global Middleware），必须通过 m.Use(...) 在路由注册前启用，且需确保：

• Session store（如 CookieStore）密钥足够安全（生产环境勿用硬编码明文）；
• 浏览器同源策略与请求路径匹配（例如：Cookie Path 默认为 /，若应用部署在子路径如 /app/，需显式设置 store.Options(sessions.Options{Path: "/app/"})）；
• 最关键：所有写入 Session 的 handler 必须返回响应（即不能 panic、未返回值、或被前置中间件拦截中断）。

你当前的 /login 处理函数存在两个高危问题：

1. defer conn.Close() 放置错误：sql.Open 返回的是连接池，不应在每次请求中 defer Close()（这会立即关闭池），应改为 defer stmt.Close() 后，在函数末尾显式调用 conn.Close()（或更佳：使用 defer func(){...}() 包裹资源释放，但推荐用 database/sql 的标准模式：连接池由 sql.DB 自动管理，无需手动 Close）；
2. log.Fatal(err) 导致进程崩溃：一旦登录失败（如密码错误触发 QueryRow().Scan() 返回 sql.ErrNoRows），log.Fatal(err) 会终止整个进程，不仅中断当前请求，更导致 Session Cookie 根本未生成/未写入 HTTP 响应头 —— 浏览器收不到 Set-Cookie，自然无法在 /session 请求中回传 session ID。

✅ 修复后的 /login 示例（关键修正）

m.Get("/login", binding.Bind(LoginForm{}), func(r render.Render, session sessions.Session, form LoginForm) string {
    // ✅ 正确使用数据库连接（连接池复用，无需 defer conn.Close）
    conn, err := sql.Open("sqlite3", "ocdns.db")
    if err != nil {
        log.Printf("DB open failed: %v", err)
        return "DB error"
    }
    defer conn.Close() // ✅ 此处 defer 安全：conn 是本次请求获取的句柄（实际是池中连接）

    stmt, err := conn.Prepare(`
        SELECT user_id, username, name_first, name_last, role, team_id
        FROM User
        WHERE username = ? AND password = ?
        LIMIT 1;
    `)
    if err != nil {
        log.Printf("Prepare failed: %v", err)
        return "SQL prepare error"
    }
    defer stmt.Close()

    var id, username, name_first, name_last, role, team_id string
    err = stmt.QueryRow(form.Username, form.Password).Scan(
        &id, &username, &name_first, &name_last, &role, &team_id,
    )

    if err != nil {
        if err == sql.ErrNoRows {
            log.Printf("Login failed for user: %s", form.Username)
            return "Bad" // ✅ 不 panic，确保响应发出
        }
        log.Printf("Query error: %v", err)
        return "DB query error"
    }

    // ✅ 安全写入 Session
    session.Set("id", id)
    session.Set("username", username)
    session.Set("name_first", name_first)
    session.Set("name_last", name_last)
    session.Set("role", role)
    session.Set("team_id", team_id)

    // ✅ 强制刷新 Session（可选但推荐，确保 Cookie 立即写入响应头）
    session.Save()

    log.Printf("Login OK for user: %s", username)
    return "OK"
})

✅ 补充验证与最佳实践

• 强制 session.Save()：虽然 martini-contrib/sessions 在 handler 结束时会自动保存，但在复杂流程（如重定向前、或嵌套中间件）中显式调用 session.Save() 可避免意外丢失。
• 检查响应头：用 Chrome DevTools → Network → 查看 /login 响应的 Headers → Response Headers，确认存在类似 Set-Cookie: my_session=xxxxxx; Path=/; HttpOnly 的字段。
• Cookie 安全选项（生产必备）：

  store := sessions.NewCookieStore([]byte("your-32-byte-secret-key-here"))
  store.Options(sessions.Options{
      Path:     "/",
      MaxAge:   86400, // 24h
      HttpOnly: true,
      Secure:   true, // 仅 HTTPS 传输（部署到 HTTPS 环境时启用）
      SameSite: http.SameSiteLaxMode,
  })
  m.Use(sessions.Sessions("my_session", store))

• 避免 log.Fatal / panic：Martini 中任何未捕获的 panic 或 os.Exit() 都会导致响应中断，Session 无法落盘。

✅ 总结

Session 跨请求失效 ≠ Session 代码写错，而是 HTTP 协议层契约未履行：服务器必须在首次写入 Session 时，通过 Set-Cookie 告诉浏览器“请记住这个 ID”；浏览器则需在后续请求中通过 Cookie 头回传它。只要确保：

1. sessions.Sessions() 全局启用且配置合理；
2. 所有写 Session 的 handler 正常返回（无 panic、无 log.Fatal）；
3. 数据库等资源清理不干扰响应流；
4. （可选）显式调用 session.Save()；

你的 Session 就能稳定工作。调试时优先检查网络面板中的 Cookie 交互，而非仅关注 Go 代码逻辑。