OpenUI5集成卡片中CSRF令牌获取失败问题解析

问题背景

在使用OpenUI5集成卡片(Integration Card)开发应用时，开发者遇到了CSRF(跨站请求伪造)令牌获取失败的问题。卡片配置中包含了CSRF令牌获取逻辑，但在实际运行时却返回404错误，而相同的请求通过前端直接发送却能成功获取令牌。

技术分析

CSRF令牌机制

CSRF令牌是现代Web应用中常见的安全机制，用于防止跨站请求伪造攻击。在SAP系统中，通常通过发送带有特殊头部的HTTP请求来获取令牌：

1. 请求方法：HEAD或GET
2. 必须包含头部：X-CSRF-Token: fetch
3. 服务器响应中会返回X-CSRF-Token头部，包含实际令牌值

集成卡片配置

在OpenUI5集成卡片中，CSRF令牌的获取是通过manifest.json文件中的csrfTokens配置节实现的。典型配置如下：

"csrfTokens": {
  "token1": {
    "data": {
      "request": {
        "url": "{{destinations.PINS_BACKEND}}/",
        "method": "HEAD",
        "headers": {
          "X-CSRF-Token": "fetch",
          "Accept": "*/*"
        },
        "withCredentials": true
      }
    }
  }
}

问题根源

通过对比分析发现，集成卡片发送的请求与手动发送的请求存在关键差异：

1. Accept头部不同：

   • 卡片发送：application/json, */*
   • 手动发送：*/*

2. 某些后端服务对Accept头部内容敏感，可能拒绝非预期的内容类型请求

解决方案

方案一：修改后端服务

使后端服务能够容忍更广泛的Accept头部值，包括application/json, */*的组合。这是最彻底的解决方案，但需要后端支持。

方案二：明确指定Accept头部

在卡片配置中显式覆盖默认的Accept头部：

"headers": {
  "X-CSRF-Token": "fetch",
  "Accept": "*/*"
}

方案三：使用HEAD方法

尝试将请求方法从GET改为HEAD，某些服务对HEAD方法的处理可能更为宽松：

"method": "HEAD"

最佳实践建议

1. 明确指定内容类型：在CSRF令牌请求中，最好明确指定Accept: */*以避免内容类型协商问题

2. 调试技巧：使用浏览器开发者工具对比卡片请求和手动请求的所有细节，包括：

   • 请求方法
   • 请求头部
   • Cookies
   • 请求URL

3. 版本兼容性：检查使用的OpenUI5版本，某些版本可能在头部处理上存在已知问题

4. 服务端日志：查看服务端日志，了解为何返回404错误，可能有更详细的拒绝原因

总结

OpenUI5集成卡片中的CSRF令牌获取问题通常源于请求头部的细微差异，特别是Accept头部的处理。通过明确指定请求头部或调整后端服务的容忍度，可以有效解决这类问题。开发者在遇到类似问题时，应当仔细对比请求细节，找出真正的差异点，从而有针对性地解决问题。