qooxdoo-compiler icon indicating copy to clipboard operation
qooxdoo-compiler copied to clipboard

XHR cookie problem when using qx serve

Open DB-CL opened this issue 3 years ago • 9 comments

Hi,

We are experiencing an issue when running a code with qx serve. And the bug is not there when running a code built with qx deploy

The bug is the following : there is not "Cookie" header set on request that are build with qx.io.rest.Resource but when we are using a qx.io.request.Xhr we have a "Cookie" header

In both case we set the withCredentials parameter to "true" with something like :

// this is pseudo-code, I skipped the request parameters
// in this case, the cookie parameter is passed when using qx serve and qx deploy
var request = new qx.io.request.Xhr();
var nativeXhr = request.getTransport().getRequest();
nativeXhr.withCredentials = true;
// this is pseudo-code, I skipped the request parameters
// in this case, the cookie parameter is passed only when using qx deploy but not when using qx serve
var resource = new qx.io.rest.Resource();
resource.configureRequest(function(request) {
    var nativeXhr = request.getTransport().getRequest();
    nativeXhr.withCredentials = true;
});

Our code is working just fine in productions stage, the cookie is always there in all cases. But the exact same code is not working anymore with qx serve.

We actually think the bug started to occur when we upgrade node from 12 to 14 but we are not sure this is related.

Any idea ?

DB-CL avatar Apr 21 '21 16:04 DB-CL

Do you use a "proper" web server in production, eg Apache or nginx?

johnspackman avatar Apr 22 '21 07:04 johnspackman

Sorry for the delay I missed the notification. Yes we are behind Nginx

DB-CL avatar May 04 '21 15:05 DB-CL

Im confused because IU'm not sure I understand exactly what you're describing - what it sounds like you're saying is that when you use qx.io.rest.Resource, then the web server built into qx serve does not return cookies? And that if you run the same code inside nginx (and without qx serve) the cookies are present?

But it seems that you are also saying that if you use the qx.ui.request.Xhr, then qx serve does return some cookies?

As I understand it, the browser is not able to store cookies on the server at all; and as the webserver inside qx serve does not issue cookies at all, I do not understand how you could be getting cookies when using qx serve. If you are getting cookies when using nginx, my guess would be that it's something to do with your nginx configuration.

Sorry not be any more helpful, but if you could put together a working example that would help a lot

johnspackman avatar May 04 '21 16:05 johnspackman

Sorry about the confusion, I will try to make it clearer.

We have no problem at all with our front being behind Nginx, everything is working the way it is supposed to work with Nginx and the build obtained with qx deploy. Our production stage is not impacted by this issue.

When we are using qx serve to serve the frontend in development stage, we have a strange behavior with qx.io.rest.Resource : a header is missing. This is the session's cookie header so we cannot test our application since the login does not work anymore (our backend does not receive the session's cookie so the flow is stopped, and when we debug the HTTP request in chrome or in PHP, we can see that this header is missing)

The strange parts is that this occurs only with queries emitted with qx.io.rest.Resource. It appears that the queries emitted with qx.ui.request.Xhr does have the session's cookie header when using qx serve

In both cases the backend is hosted with Nginx/PHP and it's exactly the same backend. We suspected CORS problem but as far as we can tell we have no evidence it's CORS related (and it's working with qx.ui.request.Xhr, and it was working a few months ago).

This problem has been observed on two different setups : one being on Windows and the other on Linux.

And again, as soon as we use the build produced with qx deploy the issue vanishes and we are able to test and deploy our application.

Thanks again for trying to understand ^^

DB-CL avatar May 05 '21 15:05 DB-CL

one big difference between qx serve and qx deploy is that qx serve will use the "source" target by default and qx deploy will always use "build"; this will cause the output code to be slightly different (because the "build" target eliminates any code inside if (qx.core.Environment.get("qx.debug")) { /* ... snip ... */ }).

Please can you try qx serve --target=build and see if this changes the behaviour?

What I don't understand still is where the cookie is coming from in the first place during development - qx serve just uses plain old ExpressJS, and there is no code in there to issue cookies.

johnspackman avatar May 05 '21 15:05 johnspackman

What I don't understand still is where the cookie is coming from in the first place during development - qx serve just uses plain old ExpressJS, and there is no code in there to issue cookies.

I don't know why the answer of Derrell has disappeared because I think he was right. qx serve serves the .js app but does not manage the cookies. The cookies are only between the browser and the backend.

The problem may come from the difference between the builds, so I'll try your suggestion and let you know.

DB-CL avatar May 06 '21 15:05 DB-CL

qx serve serves the .js app but does not manage the cookies.

Exactly.

The cookies are only between the browser and the backend.

How does that work then? Is the qx serve web server on one port and the "backend" on another port?

johnspackman avatar May 06 '21 15:05 johnspackman

How does that work then? Is the qx serve web server on one port and the "backend" on another port?

Yes, that's why we supposed it was a CORS issue, but a CORS issue won't explain the fact that it's working well with qx.ui.request.Xhr

DB-CL avatar May 12 '21 16:05 DB-CL

Please can you setup a reproducable test case?

johnspackman avatar May 13 '21 07:05 johnspackman