FitNesse RestFixture 测试无法获取访问令牌



我有带有Spring OAuth2授权的REST应用程序。我用 FitNesse RestFixture 测试对其进行了测试(我从 curl 响应中添加了令牌,最后GET操作成功):

| Table:smartrics.rest.fitnesse.fixture.RestFixture | http://10.76.243.103:8080 |
| GET | /<root>/version | | | 2.2.1 |
| setBody |grant_type=password&username=test&password=test123&scope=data+compute|
| setHeader |Authorization : Basic dGVzdDo4YmE5MjRjZS0wNThhLTQ3Y2YtOGQ4Mi02ZWY1N2Y4NzdiNmQ=|
| setHeader |Content-Type : application/x-www-form-urlencoded|
| POST | /<oauth-provider>/oauth/token | | | |
| setHeader |Authorization : Bearer fd947659-cf17-4ded-b2e8-698395c201df|
| GET | /<root>/schemas | | | | 

并且我未能在POST操作上获取访问令牌,并带有问题{"error":"unauthorized","error_description":"Full authentication is required to access this resource"}

| POST | /<oauth-provider>/oauth/token | 401 | <responce> | {"error":"unauthorized","error_description":"Full authentication is required to access this resource"} |

responce在哪里:

Server : Apache-Coyote/1.1
X-Content-Type-Options : nosniff
X-XSS-Protection : 1; mode=block
Cache-Control : no-cache, no-store, max-age=0, must-revalidate
Pragma : no-cache
Expires : 0
X-Frame-Options : DENY
Cache-Control : no-store
Pragma : no-cache
WWW-Authenticate : Bearer realm="oauth", error="unauthorized", error_description="Full authentication is required to access this resource"
Content-Type : application/json;charset=UTF-8
Transfer-Encoding : chunked
Date : Thu, 27 Nov 2014 11:17:56 GMT

如果我使用curl实用程序执行相同的操作,我成功地access_token

curl -X POST -v -u test:8ba924ce-058a-47cf-8d82-6ef57f877b6d --data 'username =test&password=test123&grant_type=password&scope=data+compute' 'http://10.76.24 3.103:8080/parseq/oauth/token' -k
* About to connect() to 10.76.243.103 port 8080 (#0) 
* Trying 10.76.243.103...
* Adding handle: conn: 0x4c3388
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x4c3388) send_pipe: 1, recv_pipe: 0
* Connected to 10.76.243.103 (10.76.243.103) port 8080 (#0)
* Server auth using Basic with user 'test'
> POST /parseq/oauth/token HTTP/1.1 
> Authorization: Basic dGVzdDo4YmE5MjRjZS0wNThhLTQ3Y2YtOGQ4Mi02ZWY1N2Y4NzdiNmQ= 
> User-Agent: curl/7.30.0 
> Host: 10.76.243.103:8080 
> Accept: */* 
> Content-Length: 69 
> Content-Type: application/x-www-form-urlencoded 
>
* upload completely sent off: 69 out of 69 bytes
< HTTP/1.1 200 OK
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1 
< X-Content-Type-Options: nosniff 
< X-XSS-Protection: 1; mode=block 
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate 
< Pragma: no-cache < Expires: 0 
< X-Frame-Options: DENY 
< Cache-Control: no-store 
< Pragma: no-cache 
< Content-Type: application/json;charset=UTF-8 
< Transfer-Encoding: chunked 
< Date: Thu, 27 Nov 2014 09:20:39 GMT 
< {"access_token":"fd947659-cf17-4ded-b2e8-698395c201df","token_type":"bearer","re fresh_token":"564aa6ca-0afa-4519-a907-e7027053bb35","expires_in":40317,"scope":" compute data"}
* Connection #0 to host 10.76.243.103 left intact

任何人都可以建议我如何调试或修复它吗?

提前感谢!

我启动了tcpdump来检查我从curl请求中发送的确切内容(如使用 TCPDUMP 监控 HTTP 流量中所述):

sudo tcpdump -A -s 0 'tcp port 8080 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

我在服务器机器上启动了它。

我发现curl自动添加了Content-Type标题:

08:55:30.504594 IP <my client DNS name>.53655 > cherry.http-alt: Flags [P.], seq      1801770313:1801770631, ack 3280862118, win 67, length 318
E..fE.@.q..q
B r
L.g....kd.I....P..C....POST /<oauth provider>/oauth/token HTTP/1.1
Authorization: Basic dGVzdDo4YmE5MjRjZS0wNThhLTQ3Y2YtOGQ4Mi02ZWY1N2Y4NzdiNmQ=
User-Agent: curl/7.30.0
Host: 10.76.243.103:8080
Accept: */*
Content-Length: 69
Content-Type: application/x-www-form-urlencoded
username=test&password=test123&grant_type=password&scope=data+compute
08:55:30.508697 IP cherry.http-alt > <my client DNS name>.53655: Flags [P.], seq 1:563, ack 318,   win 237, length 562
E..ZPB@.@...
L.g
B r........kd..P...*...HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 27 Nov 2014 13:55:30 GMT
ae
{"access_token":"fd947659-cf17-4ded-b2e8-698395c201df","token_type":"bearer","refresh_token":"564aa6ca-0afa-4519-a907-e7027053bb35","expires_in":23826,"scope":"compute data"}
08:55:30.508937 IP cherry.http-alt > <my client DNS name>.53655: Flags [P.], seq 563:568, ack 318, win 237, length 5

此外,我还检查了我从 FitNesse 测试中发送的确切内容:

08:33:36.598429 IP 10.76.243.55.39600 > cherry.http-alt: Flags [P.], seq 102:347, ack 335, win   237, options [nop,nop,TS val 859086469 ecr 41658573], length 245
E..)..@.@...
L.7
L.g........r..............
34...{..POST /<oauth provider>/oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Jakarta Commons-HttpClient/3.1
Host: 10.76.243.103:8080
Content-Length: 69
grant_type=password&username=test&password=test123&scope=data+compute
08:33:36.599047 IP cherry.http-alt > 10.76.243.55.39600: Flags [P.], seq 335:974, ack 347, win 235, options [nop,nop,TS val 41658578 ecr 859086469], length 639

我发现Authorization FitNesse 的请求中缺少标题。看起来顺序使用setHeader()方法会导致标头覆盖。因此,我将我的 FitNesse 测试更改为使用setHeaders()方法在一个表格行中设置一些标题(如如何在 RestFixtureConfig rest fixture.default.headers 中设置具有动态值的标题中所述):

| setBody |grant_type=password&username=test&password=test123&scope=data+compute|
| setHeaders |!-Authorization: Basic dGVzdDo4YmE5MjRjZS0wNThhLTQ3Y2YtOGQ4Mi02ZWY1N2Y4NzdiNmQ=
Content-Type: application/x-www-form-urlencoded-!|
| POST | /parseq/oauth/token | 200 | | | 

现在它工作正常。

最新更新