Web workers does not attach session cookies to XMLHTTP request anymore

1,612 views
Skip to first unread message

Roberto Oneto

unread,
Feb 11, 2021, 6:05:48 PM2/11/21
to Chromium Extensions
Hi everyone.
I have a problem.
A web worker created by the main backgroung script
does not include session cookies during a GET XMLHTTP request
to an ASP.NET page on an external server (server out of my control).

The responde I get is the login page when I would have expected another post-authentication page.

The request made by the main background script works,
whereas the same request made by the web worker (created by the background script) no anymore.
The same code magically returns to work using an older portable version of Iron browser (chromium).

From the developer console I verified that the session cookies are set like this: SameSite: <unset-blank> and Secure

I tried to turn the Web Worker into a Service Worker but the result doesn't change.

I tried to repeat the whole authentication process from the web worker, but to do this I have to iterate exactly what the user would do manually
that is:
1 call the login page
2 save the viewstate and other form hidden fields which will be sent with submit
3 build an url encoded string ready for send command (which obviously includes user and password field)
4 save back the viewstate and the same hidden fields of the form for any subsequent requests.

Here, however, another problem arises.

To retrieve and then save these hidden form fields, I have to parse the response with something like DOMParser
Pity that DOMParser inside the workers doesn't work!

How can I solve this problem?
The web worker job consists to call the same URL about 30 times but with different querystring parameters.
I execute these request one by one and in a strict order with a random delay between 3 and 10 seconds (I implement the delay with SetTimeout)
The response got from each request is a very simple HTML document with a TABLE that I parse (unfortunately without tools that come to my aid such as DOMParser) by hand with regular expression, trim and split, etc
Maybe it's much simpler than you think ...

Thanks for any suggestion

wOxxOm

unread,
Feb 12, 2021, 9:13:13 AM2/12/21
to Chromium Extensions, rob...@gmail.com
> does not include session cookies

You probably switched from `XMLHttpRequest` to `fetch`, which doesn't send cookies by default.
You can specify `credentials` parameter, see https://stackoverflow.com/questions/34558264/fetch-api-with-cookie

> DOMParser inside the workers doesn't work!

There are only lame workarounds like using a js parser library or opening a new tab/window.
Message has been deleted
Message has been deleted

Roberto Oneto

unread,
Feb 12, 2021, 3:53:01 PM2/12/21
to Chromium Extensions, wOxxOm, Roberto Oneto
Hi  wOxxOm,  thank you for your reply.

I have attached the code of the web worker with same comments.
I have always used XMLHTTPRequest without (and then with) withCredentials = true
Unfortunately, the result does not change.

In the PARALLEL attempt I made with the service worker, I had to use FETCH and I set the "init" object with    {credentials: 'include'}.
As you wrote, fetch does not carry cookies by default.

Now I've done a couple more tests:
Setting the   chrome: // flags / # same-site-by-default-cookies   flag to “DISABLED” the web worker returns to work exactly as before.
Obviously it is not a solution!

I added cookie permission in manifest.json and, before invoking the web worker, I changed two session cookies with chrome.cookies.set( 
so that sameSite is now None ('no_restriction')
Even with this change the web worker returns to work! (it could be the final solution, not stunning, but still a valid solution).

I still have many doubts about the new rules regarding the delivering of cross site cookies...
...and I really don't understand why if the background script has the grant to "call"a host declared in the manifest, the web worker created by the same script must not have the same grant.

Setting this session cookie via API doesn't seem like the most logical solution (but maybe it could be the only one).
Among other things, I still have to check if adding the cookies permission disable or not the extension; it would be a nuisance!

I'm ready to do more tests if needed..
Thanks

webWorker.txt

Simeon Vincent

unread,
Feb 16, 2021, 9:23:03 PM2/16/21
to Roberto Oneto, Chromium Extensions, wOxxOm
I really don't understand why if the background script has the grant to "call"a host declared in the manifest, the web worker created by the same script must not have the same grant.

Me either; sounds like a bug. Please open a bug report on crbug.com :)

Cheers,

Simeon - @dotproto
Chrome Extensions DevRel

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/51d959ca-488b-451c-b037-72ee99c22636n%40chromium.org.

Roberto Oneto

unread,
Feb 17, 2021, 6:11:11 AM2/17/21
to Chromium Extensions, Simeon Vincent, Chromium Extensions, wOxxOm, Roberto Oneto
Hi Simeon,
I have already opened a bug report with this id:    1178285: [SameSite cookies]  
Thank you for your interest.
I hope I wasn't wrong

Reply all
Reply to author
Forward
0 new messages