Supabase Auth跨域请求中X-Supabase-API-Version头的CORS配置问题解析

在Supabase Auth服务的实际部署中，开发者可能会遇到一个与跨域资源共享(CORS)相关的配置问题。这个问题主要影响使用较新版本supabase/auth-js客户端库与Supabase Auth服务进行交互的场景。

问题背景

Supabase Auth服务在v2版本中引入了一个重要的API版本控制机制。服务端和客户端通过X-Supabase-Api-VersionHTTP头来协商API版本，确保兼容性。这个机制在服务端通过特定提交实现，在客户端则通过对应的PR完成。

然而，当开发者将应用部署为跨域架构时，会发现请求无法正常工作。这是因为默认的CORS配置中缺少了对这个自定义头的支持。

技术细节分析

在HTTP的CORS机制中，当浏览器发送跨域请求时，如果请求包含非简单头部(如自定义头)，浏览器会先发送一个预检(OPTIONS)请求。服务端必须通过Access-Control-Allow-Headers响应头明确列出允许的自定义头，浏览器才会继续发送实际请求。

Supabase Auth服务的默认CORS配置中包含了常见头如Authorization、Content-Type等，但遗漏了新引入的X-Supabase-Api-Version头。这导致浏览器拦截了包含该头的实际请求，即使服务端能够处理这个头。

解决方案

对于遇到此问题的开发者，有以下几种解决方案：

1. 环境变量配置：通过设置GOTRUE_CORS_ALLOWED_HEADERS环境变量，添加X-Supabase-Api-Version到允许的头列表。这是最灵活的解决方案，允许自定义其他需要的头。

2. 修改服务端默认配置：建议Supabase Auth项目将X-Supabase-Api-Version头加入默认允许的头列表，因为这是官方客户端库使用的标准头。

3. 文档补充：至少应该在官方文档中明确说明这个配置需求，帮助开发者快速解决问题。

最佳实践建议

对于生产环境部署，建议开发者：

• 明确审查所有自定义HTTP头
• 在CORS配置中显式列出所有需要的自定义头
• 保持客户端和服务端版本的同步更新
• 在升级版本时特别注意变更日志中关于API和CORS的变更

这个问题虽然看起来是小的配置问题，但在实际开发中可能导致难以诊断的跨域请求失败。理解CORS机制和Supabase Auth的版本协商机制，有助于开发者快速定位和解决类似问题。