最近笔者在整理自己之前在 SAP 社区发布的英文博客,发现了这篇文章:
https://community.sap.com/t5/application-development-and-automation-blog-posts/just-a-single-click-to-test-sap-odata-service-which-needs-csrf-token/ba-p/13403826
文章写于 2019 年,现在已经有了比 Postman 更方便的 API 测试工具,比如 Postwoman,后者已经更名为 Hoppscotch.
尽管如此,笔者日常工作中仍然选择 Postman,因为它足以胜任我工作中的主流场景。
笔者之前的文章深入介绍 SAP OData CSRF Token 的一些技术细节提到,在 SAP OData 服务中,只要涉及写操作(新增、修改或删除),发起 OData 请求的客户端(Postman, SAP UI5 应用等等)就必须先向服务器申请 CSRF token,并在随后的实际调用里把该 token 放入 HTTP 请求头部。
若是少了这一步,服务器会直接拒绝请求。
记得我过去从事 SAP 标准 Fiori 应用的全栈开发时,需要用 Postman 测试自己实现的 SAP OData 服务。在测试 OData 服务的写操作时,每回都得在 Postman 里手工完成两件事:
1. 取 token:向服务端发送一次 GET 请求,把 HTTP 请求的x‑csrf‑token 头部字段值设置为 fetch,以换回一枚有效 token;
2. 把前一步刚拿到的 token 再填进下一条 HTTP POST 请求的头部字段里。
这一来一回既枯燥又易出错,记得当时有个同事随口一问:“这两个步骤能不能自动化完成?”
于是我研究了一下,发现可以借助 Postman 内置的脚本功能,让它自动从第一个请求的响应结果里解析出服务器颁发的 token 并添加到第二个 HTTP POST 请求的头部字段去。
详细步骤如下:
1. 点击 Postman 右上角的齿轮图标,打开 Environments 管理界面。
新建一个环境,命名为 TokenSuite,并在其中添加变量 csrftoken.
2. 在第一个取 token 的 HTTP GET 请求的 Tests 标签页里,写入脚本:
var token = postman.getResponseHeader("x-csrf-token");console.log("token:" + token);postman.setEnvironmentVariable("csrftoken", token);
脚本会把响应头里的 x‑csrf‑token 读出并存入环境变量。
3. 在下一条真正执行写操作的 POST 请求里,把请求头 x‑csrf‑token 的值设成 {{csrftoken}}.
4. 我之前在 Postman 里提前创建好了一个 Collection,命名为 CSRF token test. 将取 token 的 HTTP GET 请求和进行写操作的 HTTP POST 这两个请求依次添加到了 Collection 中。
点击 Run,在弹出的 Collection Runner 中直接按 Run CSRF token test.
两条请求便会依次执行:第一条请求拿 token,然后脚本会从 HTTP 响应结果里提取 token 值,写入第二条请求的头部字段中。整个过程无需再人工粘贴复制,一键到位,省时省心。