The cookies object recevied in the handlers varies depending on the placement of the handler within the `setupServer` function. about msw

[kettanaito]

Hi, @NZepeda!

It may not be the best idea to use @mswjs/cookie that way. You are interfering with how MSW picks up cookies that way, it seems. If you want to have an initial cookie set, mutate document.cookie instead. In other words, do what your app would do.

I also have a concern that you aren't testing anything in your test: https://github.com/NZepeda/msw-cookies-example/blob/d7d900d6e0202c8b8a522b1c88b4958b8782c181/src/test/mock.test.ts. What the test cases assert right now is that MSW handles cookies correctly. If this is a trimmed test case you created to illustrate the issue then it's okay. But if it's not, don't test third-party libraries, test your code instead.

[antoinetissier]

Hi @kettanaito,

What we are trying to simulate is a prod setup with an Http-Only, Secure cookie.
In a browser Http-Only are not readable/mutable through document.cookie.

Is there no way to set this up in msw + jsdom ?

This is related to #1586

[kettanaito]

@antoinetissier 👋

Since you cannot read the HttpOnly cookie in JavaScript, what would you test then? Nothing in your application can depend on it. I suspect you are talking about forwarding that cookie to the server request (i.e. credentials)? If that's the case, it's done by the browser for you.

Please tell me more about your test case.

[antoinetissier]

We use a cookie to authenticate a WebSocket connection to the server.
We get that cookie by sending a request to the server with a JWT, and if it is valid the server responds with a Set-Cookie header where the cookie is HttpOnly and Secure.
The cookie is stored in the browser securely (as it's not accessible through JavaScript with document.cookie), and sent upon further server requests (we adapt the credentials request property if necessary for cross-domain deployments).
As mentioned above, this allows to then open a WebSocket in particular, but the cookie can also be used to authenticate any other further HTTP request to the server (our Java uses Spring security and this is the default behavior).

When the UI assets (JS, HTML, css, etc.) are served by the server itself (which is the deployment that we recommended), then when you try connecting to the UI, you must first pass the Spring security layer before the UI assets can be fetched.
In that case, by the time any JavaScript is run, the session cookie is already set in the user's browser.

We are looking to test all this authentication flow with msw.

[NZepeda]

To add on to this, @kettanaito, as you recommended above, I've removed usage of the @mswjs/cookie package to set the cookie and instead, I'm directly mutating document.cookie. The same error persists. I've updated the linked repo to demonstrate the issue.

For the test, I've set up a server with three handlers, two of which depend on the cookies object given by the resolver function. These handlers check the cookie similarly by comparing cookies[sessionCookieName] to an expected cookie value.

Within the test suite itself, I set the session cookie once by mutating document.cookie within the beforeAll. There are two tests, each hitting a different handler. The first test passes because the cookie has the expected value. The second test fails because the cookie value is now unexpected.

This seems like a bug within msw because I expect that both tests should pass because the cookie was only mutated once in the beforeAll. I do not expect the cookies object given by the resolver to change between handlers simply due to their order within the setupServer function.

For more clarity:
This is the value of the cookies object given by the resolver in the first handler:

{ MyCookie: 'ABCD1234' } <- This is good

This is the value of the cookies object given the resolver in the third handler:

{ MyCookie: 'ABCD1234, MyCookie=ABCD1234' } <- This is bad

Can you confirm whether or not this is expected?