Mongoose项目中HTTP/HTTPS同时访问时的Cookie冲突问题解析

在Mongoose项目开发过程中，当Web UI Dashboard同时支持HTTP和HTTPS协议访问时，开发者可能会遇到一个典型的Cookie冲突问题。这个问题表现为：当用户先通过HTTPS登录后，再通过HTTP访问时，部分页面内容无法正常显示。

问题现象分析

当服务端同时开启8000(HTTP)和8443(HTTPS)端口时，会出现以下异常情况：

1. 单独使用HTTP访问时，所有功能页面都能正常显示
2. 一旦有用户通过HTTPS登录后，HTTP访问的Dashboard、Settings和Events页面会显示空白
3. 通过浏览器开发者工具查看，会发现HTTP请求返回403未授权错误

根本原因

这个问题源于现代浏览器对Cookie的安全策略限制。当HTTPS连接设置了Secure属性的Cookie后，浏览器会阻止HTTP连接设置同名的Cookie。具体表现为：

1. HTTPS连接设置的Cookie会自动添加Secure属性
2. 当HTTP尝试设置同名Cookie时，浏览器会拒绝并显示警告："尝试通过Set-Cookie标头设置Cookie的操作被禁止了，因为此标头不是通过安全连接发送的，而且会覆盖具有Secure属性的Cookie"
3. 导致HTTP请求无法携带有效的认证令牌，服务端返回403未授权响应

解决方案

Mongoose项目团队提出了两种解决方案：

1. 为HTTPS连接添加前缀标识
   最初尝试在HTTPS的Cookie值前添加"s_"前缀，但测试发现这种方法无效，因为浏览器是根据Cookie名而非值来判断冲突的。

2. 使用不同的Cookie名称
   最终有效的解决方案是为HTTP和HTTPS连接使用完全不同的Cookie名称：

static void handle_login(struct mg_connection *c, struct user *u) {
  char cookie[256];
  const char *cookie_name = c->is_tls ? "secure_access_token" : "access_token";
  mg_snprintf(cookie, sizeof(cookie),
              "Set-Cookie: %s=%s; Path=/; "
              "%sHttpOnly; SameSite=Lax; Max-Age=%d\r\n",
              cookie_name, u->access_token, 
              c->is_tls ? "Secure; " : "", 3600 * 24);
  mg_http_reply(c, 200, cookie, "{%m:%m}", MG_ESC("user"), MG_ESC(u->name));
}

技术要点总结

1. Cookie的Secure属性：标记为Secure的Cookie只能通过HTTPS连接传输，这是浏览器的重要安全特性。

2. 同源策略下的Cookie处理：即使协议不同(HTTP/HTTPS)，浏览器仍视为同一来源，会对同名Cookie进行安全校验。

3. 服务端适配：在同时支持HTTP和HTTPS的服务中，需要对认证机制做特殊处理，避免协议间的Cookie冲突。

这个问题很好地展示了在实际开发中，安全策略与功能需求之间的平衡考量。通过为不同协议使用不同的Cookie名称，既满足了浏览器的安全要求，又实现了双协议支持的功能需求。