
本文介绍在前后端分离、API 与前端部署于不同子域(如 app.mything.com 和 api.mything.com)时,如何在不显式传递 user_id 的前提下,安全、可靠地识别用户并检索其专属数据。核心方案包括共享会话存储和加密令牌化认证。
本文介绍在前后端分离、API 与前端部署于不同子域(如 app.mything.com 和 api.mything.com)时,如何在不显式传递 user_id 的前提下,安全、可靠地识别用户并检索其专属数据。核心方案包括共享会话存储和加密令牌化认证。
当 Web 应用与 API 拆分为独立子域(如 app.mything.com 与 api.mything.com)后,浏览器同源策略将阻止跨子域 Cookie 共享,导致传统基于内存或文件的会话(如 Go 的 gorilla/sessions 默认配置)失效——前端登录建立的 session 无法被 API 服务读取,进而无法从上下文隐式获取 userID。
✅ 推荐方案一:统一后端会话存储(推荐用于可控环境)
将 session 数据持久化到 API 与前端应用均可访问的共享存储中,例如 MySQL、Redis 或 PostgreSQL。以 Redis 为例(更轻量、高性能):
// Go API 服务中配置共享 session store(使用 gorilla/sessions + redisstore)
import (
"github.com/gorilla/sessions"
"gopkg.in/redis.v5"
"github.com/boj/redistore"
)
var store = redistore.NewRediStore(10, "tcp", "localhost:6379", "", []byte("secret-key"))
store.Options = &sessions.Options{
Domain: ".mything.com", // 关键:设置为父域,使 app. 和 api. 均可读写
Path: "/",
MaxAge: 86400,
HttpOnly: true,
Secure: true, // 生产环境务必启用 HTTPS
}
func handler(w http.ResponseWriter, r *http.Request) {
session, _ := store.Get(r, "auth-session")
userID, ok := session.Values["user_id"].(int)
if !ok {
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
// 执行 SELECT * FROM sometable WHERE userid = ?
}⚠️ 注意事项:
- Domain: ".mything.com" 必须带前导点号,表示该 Cookie 对所有子域有效;
- 确保前后端均使用同一密钥([]byte("secret-key"))加解密 session;
- Redis 实例需对两个服务网络可达,且做好连接池与超时配置。
✅ 推荐方案二:基于 JWT 的无状态令牌认证(更现代、可扩展)
弃用服务端 session,改由前端在登录成功后接收一个签名 JWT,后续每个 API 请求通过 Authorization: Bearer <token> 携带。API 服务验证签名并解析出 userID:
// 登录成功后签发 token(Go 示例,使用 github.com/golang-jwt/jwt/v5)
token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
"user_id": 123,
"exp": time.Now().Add(24 * time.Hour).Unix(),
})
signedToken, _ := token.SignedString([]byte("jwt-secret"))
// 前端存储于 HttpOnly Cookie 或 localStorage(推荐前者 + SameSite=Lax)
http.SetCookie(w, &http.Cookie{
Name: "auth_token",
Value: signedToken,
Domain: ".mything.com",
Path: "/",
HttpOnly: true,
Secure: true,
SameSite: http.SameSiteLaxMode,
})// API 中间件校验 JWT
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
cookie, err := r.Cookie("auth_token")
if err != nil {
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
token, _ := jwt.Parse(cookie.Value, func(t *jwt.Token) (interface{}, error) {
return []byte("jwt-secret"), nil
})
if claims, ok := token.Claims.(jwt.MapClaims); ok && token.Valid {
userID := int(claims["user_id"].(float64))
ctx := context.WithValue(r.Context(), "user_id", userID)
next.ServeHTTP(w, r.WithContext(ctx))
} else {
http.Error(w, "Invalid token", http.StatusUnauthorized)
}
})
}⚠️ 关键安全提醒
- 永远不要在 URL 或请求体中明文传 user_id —— 易被日志、代理、前端调试泄露;
- 避免使用 localStorage 存储敏感 token —— XSS 风险高;优先采用 HttpOnly + Secure + SameSite=Lax Cookie;
- 跨域需正确配置 CORS:API 响应头中设置 Access-Control-Allow-Origin: https://app.mything.com,禁用 Access-Control-Allow-Credentials: true 时不可设为 *;
- 定期轮换密钥:JWT secret 和 session 密钥应支持热更新,防止长期泄露风险。
综上,对于学习项目,建议从 Redis 共享 session 入手,逻辑直观、调试友好;面向生产或微服务演进,则推荐 JWT + 网关统一鉴权 架构,更符合 RESTful 与无状态设计原则。