带CSRF的POST请求在Postman中工作，但在cURL中失败

我向REST API发送POST请求以上载文件。在邮差一切正常。我添加了从服务器获得的基本授权和自定义CSRF（XSRF）令牌。带CSRF的POST请求在Postman中工作，但在cURL中失败

我想用cURL做同样的事情。我复制了Postman的代码，但它似乎不起作用。我相信这个错误与CSRF有关，因为如果我关闭服务器上的CSRF并且在没有CSRF令牌的情况下进行相同的cURL调用，一切正常。

现在一些细节：这就是为卷曲的命令，邮差给：

curl -X POST -H "XSRF: 79f51981-8e85-4e26-be1b-bf63aed92a42" -H "Authorization: Basic bbhjbjb=" -H "Cache-Control: no-cache" -H "Postman-Token: 76a7a43b-f407-15a2-aaff-5242b44d0f47" -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW" -F "[email protected]:\Downloads\hello-world.zip" "http://host:port/api/import"

而这对名称查询答复我--verbose

超时得到的是不支持

Trying :: 1 ...

连接到本地主机（:: 1）端口7777（＃0）

POST/API /进口HTTP/1.1

主机：本地主机：7777

的User-Agent：卷曲/ 7.47.1

接受：/

XSRF：79f51981-8e85-4e26- be1b-bf63aed92a42

授权：基本bbhjbjb =

缓存控制：无缓存

邮差令牌：76a7a43b-f407-15a2-aaff-5242b44d0f47

Content-Length：31281

expect：100-continue

Content-Type：multipart/form-data;边界= ---- WebKitFormBoundary7MA4YWxkTrZu0gW; 边界= ------------------------ 742d3475ac5f6aba

< HTTP/1.1 302实测值

<的Set-Cookie：JSESSIONID = 1qfjmbntrthxll;路径=/api < Expires：Thu，01 Jan 1970 00:00:00 GMT

< Set-Cookie：XSRF = b29bd143-cc80-49ad-b495-711125678o; Path = /; Expires = Thu，Dec-2016-Dec-2016十时28分46秒GMT

< XSRF：b29bd143-cc80-49ad-b495-711125678o <地点：

http://localhost:7777/api/login/error.jsp?errorMessage=Access拒绝

<的Content-Length：0

<服务器：码头（9.2.17.v20160517）

HTTP错误发送结束前，停止发送

关闭连接0

我可能在这里丢失了一些非常明显的东西，但是还不知道。看起来像我被重定向到登录页面，没有被正确认证，但不知道为什么（我发送XSRF在cURL中）。我也尝试在cURL中添加sessionid - 也没有工作。

任何有关在哪里搜索的想法和方向将非常感谢！

来源

2016-12-14 lenach87

您是否尝试过使用'-L'选项（因为302发现从服务器返回）添加下列选项

--cookie "csrftoken=XXXXXX;sessionid=YYYYYYY"

？ –

谢谢你的评论！我试着用-L得到类似的结果大约50次：“*连接＃1到主机本地主机完好无损 *发出另一个请求到这个URL：'http：// localhost：7777/api/login/error.jsp？errorMessage =访问+拒绝' *发现主机本地主机绑定：0x285 [可以管道] *与主机本地主机重新使用现有连接！（＃1） *连接到本地主机（:: 1）端口7777（＃1）“ – lenach87

最好的猜测是，XSRF标记是一次性标记，并且您首先在邮递员处使用它，并且它效果很好，然后在curl中使用相同的标记，而不是刷新标记，并且失败。你如何获得XSRF令牌？反正，得到1，不用先邮递员先用它，检查是否可行 – hanshenrik

目前还不清楚你的服务器端代码是如何实现的。在这里可以看到一个可见的区别是请求标题User-Agent: curl/7.47.1中的UserAgent字符串。您可以尝试添加-A "Mozilla/5.0"与您的卷曲请求。

关于上面有关XSRF 1次令牌的评论;您的服务器正在返回Set-Cookie标题作为回应。可能会发生这样的情况，即邮递员将该cookie用作第二次请求的cookie，这就是为什么它一遍又一遍地工作。您可以尝试在卷曲结束时添加-H "Cookie: XSRF=b29bd143-cc80-49ad-b495-711125678o"，看看是否有任何区别。

这些都是疯狂的猜测。最好在服务器端添加一些可以打印请求头的代码。然后提出两个请求，一个来自curl和另一个来自postman。之后检查请求标题之间的区别。这会给你一些线索。

来源

2016-12-20 11:11:35

谢谢你的建议！我会明天尝试并回复，如果有帮助 – lenach87

不幸的是，这两个头文件没有帮助:(但我会尽力为你建议添加代码，然后检查请求标题中的差异 – lenach87

-1

没有关于服务器端代码的更多信息，我也不确定。如果您使用cURL而不是邮递员拨打电话，您是否真的需要Postman-Token标头？如果从代码中删除-H“Postman-Token：76a7a43b-f407-15a2-aaff-5242b44d0f47”，它可能会起作用。

curl -X POST -H "XSRF: 79f51981-8e85-4e26-be1b-bf63aed92a42" -H "Authorization: Basic bbhjbjb=" -H "Cache-Control: no-cache" -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW" -F "[email protected]:\Downloads\hello-world.zip" "http://host:port/api/import"

来源

2016-12-21 03:51:24

谢谢您的评论，我也尝试过没有此标记 - 没有运气 – lenach87

在本post提到，随着

-H "X-CSRFToken: XXXXX"

来源

2017-03-29 13:33:12 csghone

带CSRF的POST请求在Postman中工作，但在cURL中失败

回答

相关问题