Rails 6 API + React + Google登录：登录后如何实现服务端路由授权

你目前看不到session cookie的原因，和几个跨域cookie的浏览器规则、Rails配置疏漏直接相关，和业务代码逻辑关系不大：

• 跨站场景下的SameSite限制：你的前端部署在netlify.app、后端部署在herokuapp.com，属于完全不同的站点，Rails默认生成的session cookie是SameSite=Lax属性，浏览器会直接拦截跨站POST响应里的Set-Cookie指令，根本不会写入存储。
• 跨域凭证的响应头要求不达标：带凭证的跨域响应，要求CORS返回的Access-Control-Allow-Origin必须精准匹配前端域名，不能用通配符*；同时需要明确把Set-Cookie列入可暴露的响应头范围，否则浏览器会把响应里的Set-Cookie头直接过滤掉。
• 存储位置的认知偏差：HttpOnly属性的session cookie只会挂载在后端域名的存储下，你在开发者工具的Application面板需要切到对应后端域名的Cookie条目查看，在前端域名的存储区域是找不到的，不要误判为没有写入成功。
• 你之前在ApplicationController里引入ActionController::Cookies的操作，在api-only模式下是必要的，因为默认的API控制器不会自动挂载cookie处理逻辑，这部分操作没有问题。

方案1：Rails内置Cookie Session打通 #

这是你目前投入最多的方案，只要补齐缺失的配置就能正常运行，不需要完全推翻：

• 在config/application.rb里补充跨站cookie的必要配置：

# 关闭api模式下不必要的CSRF校验
config.action_controller.default_protect_from_forgery = false
# 跨站场景必须把cookie的SameSite属性设为*None*
config.action_dispatch.cookies_same_site_protection = :none
# SameSite=None的cookie必须搭配Secure属性，仅在HTTPS下传输
config.force_ssl = true

• 修正Rack::Cors配置，避免预检请求拦截：

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://my-frontend-app.netlify.app' # 必须精准匹配域名，不能用通配符
    resource '*',
      credentials: true,
      headers: :any,
      methods: [:get, :post, :options], # 补上OPTIONS预检请求的放行
      expose: ['Set-Cookie'] # 显式暴露Set-Cookie头给前端响应
  end
end

配置完成后，你可以在网络面板查看登录接口的响应，如果能看到格式为Set-Cookie: _app_session=xxx; HttpOnly; SameSite=None; Secure的响应头，就说明后端已经正常下发cookie，后续请求带credentials: include配置时，浏览器会自动携带这个cookie完成身份校验。

方案2：直接在Cookie存储用户标识/JWT #

这个方案和Cookie Session的逻辑高度相似，区别只是Rails不再用内置的CookieStore托管加密的session数据，而是由你直接把用户ID、加密后的JWT作为HttpOnly cookie的值返回。整体开发量并没有显著增加，只是需要自己实现cookie的过期时间、签名校验逻辑，本质和方案1的浏览器交互规则完全一致。

方案3：Authorization头携带JWT的无状态鉴权 #

这个方案完全不需要依赖cookie和session，很多人对流程有误解：

• 后端在校验完Google ID token之后，直接在登录接口的JSON响应体里返回一个短期有效的自签名JWT，完全不需要通过cookie传输。
• 前端拿到JWT之后存在页面内存中，后续发请求时手动把token附加到Authorization: Bearer <token>请求头里，后端从请求头解析、校验JWT的签名和有效期，完成身份识别，整个流程是纯无状态的。

你目前在试的“后端将JWT放在自定义响应头返回、前端把JWT存在cookie中、后续请求再从cookie取出放到Authorization头”的实现，存在两个明显的问题：

• 如果存储的cookie是可被JS读取的普通cookie，一旦页面出现XSS漏洞，攻击者可以直接窃取cookie中的JWT，冒充用户身份操作。
• 手动从cookie读取JWT再拼请求头的逻辑，容易出现疏漏（比如cookie过期处理、跨域读取失败），稳定性远不如浏览器自动携带的HttpOnly cookie，或者内存中存储的JWT。

内容的提问来源于stack exchange，提问作者eberleant