qooxdoo-compiler
qooxdoo-compiler copied to clipboard
XHR cookie problem when using qx serve
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 ?
Do you use a "proper" web server in production, eg Apache or nginx?
Sorry for the delay I missed the notification. Yes we are behind Nginx
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
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 ^^
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.
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.
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?
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
Please can you setup a reproducable test case?