Skip to content
This repository has been archived by the owner on Nov 8, 2022. It is now read-only.

XHR cookie problem when using qx serve #812

Open
DB-CL opened this issue Apr 21, 2021 · 9 comments
Open

XHR cookie problem when using qx serve #812

DB-CL opened this issue Apr 21, 2021 · 9 comments

Comments

@DB-CL
Copy link

DB-CL commented Apr 21, 2021

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 ?

@johnspackman
Copy link
Member

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

@DB-CL
Copy link
Author

DB-CL commented May 4, 2021

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

@johnspackman
Copy link
Member

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

@DB-CL
Copy link
Author

DB-CL commented May 5, 2021

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 ^^

@johnspackman
Copy link
Member

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.

@DB-CL
Copy link
Author

DB-CL commented May 6, 2021

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.

@johnspackman
Copy link
Member

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?

@DB-CL
Copy link
Author

DB-CL commented May 12, 2021

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

@johnspackman
Copy link
Member

Please can you setup a reproducable test case?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants