升级Python3.9和Django3.2后CentOS7服务器django-cors-headers CORS异常问题

可行解决方案 #

1. 修复django-cors-headers版本与配置变量不兼容问题
   这是本地正常、服务器异常的最高概率原因：
   Django 3.2 要求配套 django-cors-headers >= 3.10.0，该版本已经将旧配置项 CORS_ORIGIN_ALLOW_ALL 废弃，替换为 CORS_ALLOW_ALL_ORIGINS。你本地环境可能安装的是低版本corsheaders兼容旧变量，服务器安装的是高版本导致旧配置不生效，直接替换配置项即可：

# 替换原有 CORS_ORIGIN_ALLOW_ALL = True
CORS_ALLOW_ALL_ORIGINS = True

如果业务需要跨域携带cookie，不建议开启全局允许跨域，可改用CORS_ALLOWED_ORIGINS配置明确的跨域源列表，避免和CORS_ALLOW_CREDENTIALS = True 触发高版本corsheaders的安全校验拦截。

2. 修正CORS允许头的配置错误
   你当前的CORS_ALLOW_HEADERS里存在错误配置，两个请求头被写在了同一个字符串中，会导致这两个头不被识别放行：

# 错误写法
"X-Requested-With, Content-Type",

拆分为两个独立的字符串项即可：

"X-Requested-With",
"Content-Type",

3. 检查服务器反向代理配置
   如果CentOS服务器上用了Nginx/Apache等反向代理转发请求到Django服务，绝大多数同类问题都是OPTIONS预检请求被代理直接拦截返回，没有走到Django的cors中间件处理：

• 可以在反向代理配置中添加OPTIONS请求的专属处理规则，直接返回正确的CORS响应头，或者配置代理把所有OPTIONS请求完整转发到后端Django服务
• 同时确认代理配置没有覆盖掉Django返回的Access-Control-*系列响应头

4. 确认服务器运行的配置无覆盖
   检查服务器上加载的生产环境配置没有覆盖你写的CORS相关配置，也没有其他自定义中间件在CorsMiddleware之前修改响应头，你当前的CorsMiddleware放在CommonMiddleware之前的顺序是符合官方要求的，无需调整。

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