Express中如何在预检OPTIONS请求中识别客户并设置动态Origin？

你的核心问题是OPTIONS预检请求不携带自定义Customer-Token头，导致无法识别客户并返回合规的Access-Control-Allow-Origin值，同时不能直接返回请求Origin而失去客户配置的意义。以下是几个可行的解决思路：

方案一：通过Origin预先匹配客户（预检阶段严格校验） #

如果每个客户的网站Origin是唯一的（或可通过Origin关联到唯一客户），可以在数据库中给客户数据增加origin索引，或者维护一个Origin -> 客户的映射表，在OPTIONS请求阶段直接通过Origin查找客户，再验证该Origin是否在客户的允许列表中：

// 单独处理所有OPTIONS请求，放在全局CORS配置之前
app.options('*', async (req, res) => {
  const origin = req.headers.origin;
  if (!origin) {
    return res.sendStatus(200);
  }

  // 通过Origin查找对应客户
  const customer = await getCustomerByOrigin(origin);
  let isValidOrigin = false;

  if (customer) {
    // 验证该Origin是否在客户的允许列表内
    isValidOrigin = customer.allowOriginUrls.includes(origin) || whiteListedOrigins.includes(origin);
  } else {
    // 检查是否在全局白名单
    isValidOrigin = whiteListedOrigins.includes(origin) || whiteListedOrigins[0] === "*";
  }

  if (isValidOrigin) {
    res.setHeader("Access-Control-Allow-Origin", origin);
    res.setHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS, PUT, PATCH, DELETE");
    res.setHeader("Access-Control-Allow-Headers", `X-Requested-With, Content-Type, ${customHeaders.join(", ")}`);
    res.setHeader("Access-Control-Allow-Credentials", true);
    res.sendStatus(200);
  } else {
    res.sendStatus(403);
  }
});

// 修改全局CORS配置，移除默认的*（避免与credentials冲突）
app.use(function(req, res, next) {
  res.setHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS, PUT, PATCH, DELETE");
  res.setHeader("Access-Control-Allow-Headers", `X-Requested-With, Content-Type, ${customHeaders.join(", ")}`);
  res.setHeader("Access-Control-Allow-Credentials", true);
  next();
});

优缺点：

• 优点：预检阶段就完成严格校验，符合CORS规范
• 缺点：依赖Origin与客户的唯一绑定，若多个客户共享同一Origin则无法使用

方案二：将Token存入Cookie（复用现有客户识别逻辑） #

浏览器在发送带withCredentials: true的请求时，OPTIONS预检会携带Cookie。可以让前端将Customer-Token存入Cookie，后端从Cookie中获取Token识别客户：

// OPTIONS请求处理中间件
app.options('*', async (req, res) => {
  const origin = req.headers.origin;
  if (!origin) {
    return res.sendStatus(200);
  }

  // 从Cookie获取客户Token
  const token = req.cookies['Customer-Token'];
  if (!token) {
    return res.sendStatus(403);
  }

  const customer = await getCustomerByToken(token);
  const isValidOrigin = customer.allowOriginUrls.includes(origin) 
    || whiteListedOrigins.includes(origin) 
    || whiteListedOrigins[0] === "*";

  if (isValidOrigin) {
    res.setHeader("Access-Control-Allow-Origin", origin);
    res.setHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS, PUT, PATCH, DELETE");
    res.setHeader("Access-Control-Allow-Headers", `X-Requested-With, Content-Type, ${customHeaders.join(", ")}`);
    res.setHeader("Access-Control-Allow-Credentials", true);
    res.sendStatus(200);
  } else {
    res.sendStatus(403);
  }
});

注意：

• 前端需要设置Cookie的Domain、Path、SameSite等属性确保跨域携带
• 需额外处理CSRF风险，比如同时使用CSRF令牌

优缺点：

• 优点：复用现有getCustomerByToken逻辑，无需修改客户配置结构
• 缺点：需要前端配合修改Token存储方式，增加Cookie跨域配置成本

方案三：预检宽松放行，实际请求严格校验（推荐） #

这种方式妥协预检请求的校验，但在实际业务请求中严格验证Origin与客户的绑定关系，既解决CORS报错问题，又不丢失客户自定义Origin配置的意义：

// 处理OPTIONS预检请求，直接返回请求Origin
app.options('*', (req, res) => {
  const origin = req.headers.origin;
  res.setHeader("Access-Control-Allow-Origin", origin || "*");
  res.setHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS, PUT, PATCH, DELETE");
  res.setHeader("Access-Control-Allow-Headers", `X-Requested-With, Content-Type, ${customHeaders.join(", ")}`);
  res.setHeader("Access-Control-Allow-Credentials", true);
  res.sendStatus(200);
});

// 修改全局CORS配置，移除默认*
app.use(function(req, res, next) {
  res.setHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS, PUT, PATCH, DELETE");
  res.setHeader("Access-Control-Allow-Headers", `X-Requested-With, Content-Type, ${customHeaders.join(", ")}`);
  res.setHeader("Access-Control-Allow-Credentials", true);
  next();
});

// 加强customerMiddleware的校验逻辑
const customerMiddleware = async (req, res, next) => {
  const token = req.headers['Customer-Token'];
  const origin = req.headers.origin;
  
  if (!token || !origin) {
    return res.sendStatus(401);
  }

  const customer = await getCustomerByToken(token);
  const { allowOriginUrls = [] } = customer;

  // 严格验证Origin是否属于客户允许列表
  const isValidOrigin = allowOriginUrls.includes(origin) 
    || whiteListedOrigins.includes(origin) 
    || whiteListedOrigins[0] === "*";

  if (!isValidOrigin) {
    return res.sendStatus(403);
  }

  res.setHeader("Access-Control-Allow-Origin", origin);
  req.customer = customer;
  next();
};

原理：

• 预检请求仅做CORS基础校验，放行请求Origin
• 实际业务请求时，通过Customer-Token获取客户数据，再验证Origin是否在客户允许列表中，不符合则直接拒绝

优缺点：

• 优点：实现简单，无需前端改动，实际请求的校验完全保留客户配置的有效性
• 缺点：预检请求未做严格校验，但恶意请求即使通过预检，也无法通过后续业务逻辑的校验，安全性不受影响

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