Testcafe-hammerhead: How to pass request headers using testcafe proxy for success response (getting 222)

[vbaprojectgit]

I am using TestCafe v1.8.7 in with testcafe-react-selector v3.3.0

I’m trying to login to server with my local code, while login request passes, and GraphQL request (with Apollo) passes as well, I can't pass the registration to SignalR events on server side: I’m getting 222 response on this particular request, while on Wireshark the same request seems to get 200 response. I assume that it's is only testcafe proxy issue. I also tried to use RequestHook but it didnt help.

NOTE: the request header contains the ORIGIN but the response doesn’t contains the Access-Control-Allow-Origin.

Request that succeeded (remote code is tested):
http://172.16.20.205/VisionHubWebApi/signalr/negotiate?clientProtocol=1.5&sessionToken=dda5e074-0c4b-4d47-80bd-9411b4a0550e&connectionData=%5B%7B%22name%22%3A%22notificationhub%22%7D%5D

Request:

GET /VisionHubWebApi/signalr/negotiate?clientProtocol=1.5&sessionToken=dda5e074-0c4b-4d47-80bd-9411b4a0550e&connectionData=%5B%7B%22name%22%3A%22notificationhub%22%7D%5D HTTP/1.1
Host: 172.16.30.205
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36
content-type: application/x-www-form-urlencoded; charset=UTF-8
Accept: */*
**Origin: http://localhost:3000**
Referer: http://localhost:3000/VHConfigurator/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Response:

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
Expires: -1
Server: Microsoft-IIS/8.5
**Access-Control-Allow-Origin: http://localhost:3000**
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Sun, 28 Jun 2020 13:51:24 GMT



md5-2d8ba3f21162e6b7e6406be5a5947db7



Request:

GET /jy_913qpQ/http://172.16.20.205/VisionHubWebApi/signalr/negotiate?clientProtocol=1.5&sessionToken=81afc732-58c3-4213-b60f-cf25d0483b64&connectionData=%5B%7B%22name%22%3A%22notificationhub%22%7D%5D HTTP/1.1
Host: 172.16.32.109:64781
Connection: keep-alive
**x-hammerhead|xhr|origin: http://localhost:3000**
x-hammerhead|xhr|request-marker: true
x-hammerhead|xhr|with-credentials: true
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36
content-type: application/x-www-form-urlencoded; charset=UTF-8
Accept: */*
Referer: http://172.16.20.109:64781/jy_913qpQ/http://localhost:3000/VHConfigurator/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9



md5-c125f655fadd7bf8fe8fc51fc16015fb



Response:

HTTP/1.1 222 unknown
content-type: text/html
Date: Sun, 28 Jun 2020 13:47:16 GMT
Connection: keep-alive
Transfer-Encoding: chunked



md5-89397cb235f4149cd75f281a353c2b05



import LoginPage from './PageModels/LoginPageModel.e2e';
import { ClientFunction ,RequestLogger ,RequestHook } from 'testcafe';
import { waitForReact } from 'testcafe-react-selectors';

const URL = `localhost:3000/VHConfigurator/login`;

class myRequestHook extends RequestHook {
    constructor () {
        super();
    }

    async onRequest (e) {
        e.requestOptions.headers['Access-Control-Allow-Origin'] = '*';  
    }

    async onResponse (e) {

    }
}

const customHook = new myRequestHook()

fixture (`Login to Pegasus`)
    .page (URL)
    .requestHooks( [customHook])
    .beforeEach(async () => {
        await waitForReact();
    });

test
.requestHooks([logger,customHook])
('Login with admin user, success', async t => {
    const getLocation = ClientFunction(() => document.location.href);

    await t
        .typeText(LoginPage.usernameInput,'user', { replace: true, paste: true })

[miherlosev]

Hi @vbaprojectgit

Based on the information you shared, the issue is that the SignalR server doesn't add the Access-Control-Allow-Origin header to the responses. I recommend you run your tests with the latest TestCafe version (1.8.8-alpha.3). If this doesn't help, please create a simple example demonstrating the issue or give us access to your application.

[vbaprojectgit]

Hi,

Attaching an example demonstrating the issue. TestCafe version updated to 1.8.8-alpha.3.
There is VS2017 server (run on IISExpress) and client application that need to update API_BASE_URL in it.

The issue reproduces when running: testcafe chrome .srctest.ts
The Response 222 is seen via Fiddler and looks:

Running it without the test works and adds the correct response headers.
Thanks,
Waiting for your reponse.
signalrclient.zip

signalrserver.zip

[vbaprojectgit]

Hi,
I found the issue,
Request sent via TestCafe changes the "Origin" header to "origin" ( lower case)
and since our code relate the the initial header we have not respond with the AccessControlAllowOrigin header as well.

Please consider fixing it

[AlexKamaev]

@vbaprojectgit
Thank you for your cooperation. I was able to reproduce the issue. You are correct, the cause of it is in the difference between "Origin" and "origin".
Please note that according to standards, headers are case-insensitive: https://developer.mozilla.org/en-US/docs/Glossary/HTTP_header. So, it's not directly related to our product and I suggest you try to fix it on your side.

However, for better compatibility, I think we can consider improving this behavior in the future.

[shyedhu]

Hi @AlexKamaev, Do we have further update for improving above behavior?

[AlexKamaev]

@shyedhu
We do not have any updates at the moment.

However, if you have a similar issue you can try the Custom Request Hooks approach - initialize your custom hook as follows to modify your request header:

class Hook extends RequestHook {
    constructor () {
        // No URL filtering applied to this hook
        // so it will be used for all requests.
        super();
    }

    onRequest (e) {
        if (e.requestOptions.headers['origin'])
            e.requestOptions.headers['Origin'] = e.requestOptions.headers['origin'];
    }

    onResponse (e) {
    }
}

I tested this workaround only in the initial project, so in your case, the workaround can differ.

[shyedhu]

@shyedhu
We do not have any updates at the moment.

However, if you have a similar issue you can try the Custom Request Hooks approach - initialize your custom hook as follows to modify your request header:

class Hook extends RequestHook {
    constructor () {
        // No URL filtering applied to this hook
        // so it will be used for all requests.
        super();
    }

    onRequest (e) {
        if (e.requestOptions.headers['origin'])
            e.requestOptions.headers['Origin'] = e.requestOptions.headers['origin'];
    }

    onResponse (e) {
    }
}

I tested this workaround only in the initial project, so in your case, the workaround can differ.

Hi @AlexKamaev I tried above work Custom Request Hooks approach and modified the header also , it doesn't work here . Here's testcafev1.10.0-rc.7 i tried on today . so please help us to provide correct workaround for the issue 222

[AlexKamaev]

@shyedhu If the fix from 1.10.0-rc.7 does not help, this means that the cause of the issue is different. However, it's difficult to determine it without an example that demonstrates the issue. Please create a sample project, which will help us to reproduce the issue on our machines, or share a public URL to your project. If you cannot share your project here, you can send it at [email protected].

Please note that our policy prevents us from accessing internal resources without prior written approval from a site owner. If you want us to further research the problem directly on your side, please ask the website owner to send us ([email protected]) a written confirmation. It must permit DevExpress personnel to remotely access the website and its internal resources for research/testing/and debugging purposes.

[shyedhu]

@AlexKamaev

Thanks for your response ! Here’s sample project to reproduce the statusCode: 222 for one of API which we mentioned in page.test.js

https://github.com/javenkn/testcafe-poc

Here’s console log you could see end of the test run . Please let us know if you have further questions . Thanks in advance for your good support !

response: {
      statusCode: 222,
      timestamp: 1608058244426,
      headers: {},
      body: undefined
    }
  }
]

[aleks-pro]

Hello @shyedhu,

Thank you for the sample. On my side, the test fails on the navigate to checkout step. Possibly, it happens because of the internal TestCafe problem. I created a separate issue regarding this behavior: https://github.com/DevExpress/testcafe-hammerhead/issues/2514. Please refer to it to be informed about our progress.

[shyedhu]

Hi @aleks-pro , Thank You so much for confirming that you are able to reproduce the statusCode: 222 and also appreciate on your help for creating the separate issue regarding this behavior: #2514