When making a call to a backend api with authorization header, the call will go untouched to the backend server. Note this problem only started happening in version 1.8.5 (1.8.4 is working fine)
Example of curl req going through testcafe to httpbin.org
Note the authorization header does not make it to httpbin.org
curl 'http://<localhost ip>:49748/lRd4kqmG3/https://httpbin.org/headers' \
-H 'Connection: keep-alive' \
-H 'accept: application/json, text/plain, */*' \
-H 'authorization: Bearer ya29.xxxxxxxxxxxxxx' \
-H 'content-type: application/json;charset=UTF-8' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4156.0 Safari/537.36' \
-H 'x-hammerhead-origin: https://my.website.com' \
-H 'x-hammerhead-credentials: same-origin' \
-H 'Referer: http://<localhost ip>:64928/HmgivWWBJ/https://my.website.com/' \
-H 'Accept-Language: en-GB,en-US;q=0.9,en;q=0.8' \
--compressed \
--insecure
{
"headers": {
"Accept": "application/json, text/plain, */*",
"Accept-Encoding": "deflate, gzip",
"Accept-Language": "en-GB,en-US;q=0.9,en;q=0.8",
"Content-Type": "application/json;charset=UTF-8",
"Host": "httpbin.org",
"Origin": "https://my.website.com",
"Referer": "https://my.website.com/",
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4156.0 Safari/537.36",
"X-Amzn-Trace-Id": "Root=1-5ecc53fb-b2c915fe220a7580f83xxxxx"
}
}
Expect the request to pass to backend server intact with all headers.
Your website URL (or attach your complete example):
Your complete test code (or attach your test files):
Your complete configuration file (if any):
Your complete test report:
Screenshots:
see curl above
command-line arguments: testcafe chromium:headless tests/** -s path=reports,takeOnFails=true --reporter html:reports/report.html --skip-js-errors
browser name and version: Chromium 85.0.4156.0
Hi @wilsonfan
Thank you for the provided information. We will research this issue.
We are also experiencing the same issue and have been able to reproduce the issue as described here.
Update: In case this helps, one of our engineers was able to narrow down the issue to this commit: https://github.com/DevExpress/testcafe-hammerhead/commit/5cef3cbdf3cbb2176f3aec923fded72e51dcac00
@adewinter Thank you for your comment, we'll take it into account.
Hello @adewinter and @wilsonfan,
The behavior where the authorization header was removed is expected. A request should contain our x-hammerhead-authorization custom header instead of authorization to work correctly. Therefore, we need to know how this request was created on the client side.
Could you please create a simple sample that sends a client request with the authorization header to the server?
We are experiencing the same issue
We use axios and fetch on the client side. And we are experiencing problem only with fetch request. authorization header is not get wrapped in x-hammerhead-authorization.
Looks like something related to fetch processing was changed in 1.8.5 release since this problem doesn't exist in 1.8.4
We also use fetch on the client side and experience the same problem in 1.8.5
This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.
well, confirm it is fixed in testcafe: 1.8.7 which contains the newest testcafe-hammerhead released yesterday.
Same/similar issue for us, we use Fetch API client-side and read authorization header from the previous response headers to insert into subsequent request.
This subsequent request is sent without authorization header (and with x-hammerhead-authorization: null).
The interesting thing is that during debugging we realized that response.headers.get('authorization') returns null, while response.headers.entries() iterator contains correct authorization key and its value.
I can confirm that it works in testcafe 1.8.4 but does not work in either 1.8.5, 1.8.7, 1.9.0 or 1.9.4.
May it be related to https://github.com/DevExpress/testcafe-hammerhead/commit/5cef3cbdf3cbb2176f3aec923fded72e51dcac00, https://github.com/DevExpress/testcafe-hammerhead/commit/c6ae1e18340267924172e1b7666909525174ae30?
Thank you for the information. I've reproduced this issue.
Most helpful comment
We also use fetch on the client side and experience the same problem in 1.8.5