Testcafe: No authenthication on a SPA with User Role

[iexplore]

Not sure if this a bug, missing features or just my mistake but I can't get authenticated on a SPA with testcafe user roles.

I have build a (Polymer) SPA which uses a Drupal 7 backend,
The login takes place on a normal webpage on the Drupal(/user/login) server before the SPA get's started. After logon you can go to a URL-path (on the same domain) which points to the index.html which kickstarts the SPA and downloads the other files. From the SPA the ajax-requests are made with "withCredentials" so that cookies (on the domain) are send with the request so we have an authenticated session.

I am using testcafe with user roles which allows me to logon on the Drupal site and do some things on the website being logged in. When I "navigateTo" the URL-path which start de SPA download the SPA is started just fine within the proxy, but there is no session-cookie being forwarded with the ajax-calls.
I am not sure how I can test this any further (with t.debug() you cannot see any cookies).

Some code example:
const dirkUser = Role('http://test.dirk.e-wise.com/user/login', async t => {
await t
.typeText('#edit-name', 'dirk')
.typeText('#edit-pass', 'PASSWORD')
.click('#edit-submit');
});

test('Logging in', async t => {
await t
.useRole(dirkUser)
.navigateTo('http://test.dirk.e-wise.com/app/lesson/1766/page/1')
.debug()
.expect(p.nextButton.exists).ok("No next button present")
.click(p.nextButton);
....

Software:
Windows 10
Testcafe 0,15,0
NodeJS 7.6.0

I cannot provide URL for external testing because the application is not a public server yet, but I hope the given information is sufficient.

[iexplore]

The problem is probably caused by the fact that Drupal makes it a HttpOnly cookie and that can't be read from javascript (client site).

If this is true is there another way to login (e.g just remember the cookie given)?

[LavrovArtem]

@iexplore Thanks for your information but we can't make any conclusions from it. Could you please provide us a simple example where we can reproduce the problem.

[iexplore]

@LavrovArtem It is not easy to provide a "simple" testing enviroment. Is it possible with the information / code provided to give a few pointers / suggestions? I will do the testing / analysing and report back about the solution.

[AlexanderMoskovkin]

Hi @iexplore,

I've tried to run tests on a Drupal demo that uses http only cookie for login, it works properly. So it seems the problem relates to the second part of your case when drupal login is done and the SPA requests content. We need some additional time to investigate your case and compose some detailed questions for you that can help us to resolve the problem.
Meanwhile could you please to try to run your test with the latest TestCafe alpha version (0.16.0-alpha3). We've fixed some bugs in our proxy since the 0.15.0 version, it possible it can help.
To install the latest alpha version call npm install testcafe@alpha

[iexplore]

Hi @AlexanderMoskovkin,

I am very sorry, after further investigation it shows I was wrong with my conclusion.

The problems lies in the fact that in Chrome the window.location is different because of the proxy when testcafe is running. I found that the contents of window.location in Chrome gives the complete URL incl. the proxy. From this the routing in app whent wrong which gave the impression of not being authenticated.

Other browsers work fine (IE, Edge and Firefox). To be sure I removed all extensions but the problems remains.

[AlexanderMoskovkin]

If you type window.location.href into console in Chrome developer tools during test run and see a proxied url - it's ok. In fact, if you write window.location.href in your script it's wrapped by our proxy and returns original url, not the proxied one.
(to see how it works you can type into console:
window.location.href - it returns https://proxiedUrlPart/originalUrlPart.
But if you type __get$(window,"location").href it returns only original url part)

So, as I understand the problem is reproduced in Chrome only and the test works fine in other browsers, yes?

If so could you please try to run the test in chrome in incognito mode:
testcafe "chrome --incognito" test.js
And have you tried the latest alpha version of TestCafe?

[iexplore]

Except for Chrome the other browsers work fine.

I have installed TestCafe 0.16.0-alpha3 and tried it in incognito mode but still the same problem.

I saw that in the console the window.location.href is always the real href (in any browser).
But in my app (in Chrome) I do a console.log("EwApp:_urlChanged Location is " + window.location.href); and there I can see the 'real' url with the proxy in it:

EwApp:_urlChanged Location is http://192.168.0.196:52804/Sy9GzejW-/http://cme.dirk.e-wise.com/app/lesson/1766/page/1

The strange thing is if I type in console __get$(window,"location").href it returns the right href

"http://cme.dirk.e-wise.com/app/lesson/1766/page/1"

[iexplore]

Maybe it matters; Code is using ES2015 and is transpiled JIT (in the browser) via Babel in the browser

[AlexanderMoskovkin]

Maybe it matters; Code is using ES2015 and is transpiled JIT (in the browser) via Babel in the browser

I suppose it should work in the same way in all browsers, but it seems you have a chrome-specific problem. But we'll check this too

[AlexanderMoskovkin]

@iexplore, thanks for your info. There are some uncertainties that can't allow us to draw certain conclusions. Could you please make a screencast to see how the problem looks. It can help us a lot.
We would like to see the following:
1) Run the test with TestCafe in chrome. Please let us see the address bar and opened developer tools (with opened network and console tabs), like on the screenshot: https://www.screencast.com/t/M0lkyvu0X9H
2) Do the same acitons (like in the test) on your site without TestCafe (we will see how it should work).

To create a screencast you can use any tools (for example Jing, it's free). If you would like to do it confidentially you can send a screencast to my email or via direct message on our forum

[iexplore]

@AlexanderMoskovkin Now that I knew it is not related to authentication if have done a little experiment to try to quickly reproduce the problem and it shows easy to reproduce. The problem arises with the most basic HTML example of Polymer. My suggestion is that you do the installation so you can really debug it. It will only take a couple a minutes.

Install Polymer-cli with
npm install -g bower and npm install -g polymer-cli

Create an empty directory and type polymer init
Choose for "A simple polymer-1-application' (option 3) and name the app 'testcafe'

You can run the application by typing polymer serve -p8081 (port is optional and can be anything)

Now, to be able to see to wrong URL the easiest way is to place <script>console.log("Index: href is " + window.location.href); </script> in de index.html (here you will see everything oke) and place the following code in src/testcafe-app/testcafe-app.html after the properties:
......
properties: {
prop1: {
type: String,
value: 'testcafe-app',
},
},

ready: function(){ console.log("Ready: href is " + window.location.href); }
});

The only addition is the ready function which shows the href.
If you call this page with something like this you can inspect the output on the console
...
test('test', async t => {
await t
.navigateTo('http://localhost:8081/');
await t
.debug()
..

When running the code, the first href from index is correct, but the second shows the real href (with proxy).
Let me know if you have any problems of want to handle it differently.
Thanks

[LavrovArtem]

@iexplore Thanks for your information, I've reproduced the problem and will investigate it.

[LavrovArtem]

I opened new issue in our proxy https://github.com/DevExpress/testcafe-hammerhead/issues/1161

[iexplore]

Oke, closing this one.

[AlexanderMoskovkin]

@iexplore Let's keep it opened to track a progress. We'll close this once we fix the bug in testcafe-hammerhead and the testcafe-hammerhead version will be updated

[lock[bot]]

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.