`set-cookie` header is ignored by `fetch()` inside load function

[Nickersoft]

Describe the bug

Hey folks,

Not sure if this is by design or not, but a rather annoying issue I've encountered is that all set-cookie headers returned from the fetch method inside load() are ignored and do not store a cookie on the browser. When I use the non-load fetch (global fetch) inside my +layout.ts file, it works perfectly.

However, I'm currently using URQL and its authExchange feature to make authenticated requests to my API, then refresh the access token when it expires. Unfortunately:

• Using the fetch inside load() makes the credentialed request correctly, but fails to set the new access token cookie when a response is returned
• Using the global fetch can't make any credentialed request without manually passing in the cookies, yet it will assign the new access token cookie correctly if it receives a response

I would try passing my cookies in as layout data from the +layout.server.ts to the +layout.ts and then pass a custom fetch function to URQL that manually assigns the cookies, but I'm not sure if this could lead to stale cookies (I don't know when the +layout.server.ts's load() function would run again).

I've also tried using hooks.server.ts to manually assign the cookies from set-cookie to the event object, but I think event must be a copy or immutable because it doesn't make a difference.

Hopefully I'm making sense. I know it's a bit confusing! I've scoured the docs and the issues here and can't find anything to point me in the right direction.

Reproduction

I created a small reproduction on the nickersoft/set-cookie branch of this repo. Once you install deps with (P)NPM, just run node server.js in one terminal, and then pnpm dev in another. After opening the site, if you check the developer tools you'll see no cookie is set, however in the terminal the response is logged, which includes a set-cookie header that attempts to set an access_token cookie to hello_world.

Logs

No response

System Info

System:
    OS: macOS 12.3.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 101.94 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 18.9.0 - ~/.asdf/installs/nodejs/18.9.0/bin/node
    npm: 8.19.1 - ~/.asdf/plugins/nodejs/shims/npm
  Browsers:
    Brave Browser: 107.1.45.116
    Safari: 15.4
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.86 
    @sveltejs/kit: next => 1.0.0-next.531 
    svelte: ^3.52.0 => 3.52.0 
    vite: ^3.2.2 => 3.2.2

Severity

serious, but I can work around it

Additional Information

The only current way around this is not trying to server load my GraphQL queries in my app. It causes the layout to jump once it loads data, which is unfortunately not a great UX.

[dummdidumm]

Is your API on the same domain? If not, cookies are not forwarded due to security considerations (as in the reproducible, the port means it's a different origin). You can forward them manually though.

That said, I'm wondering if our logic is too strict here. We already have some logic that forwards the cookies in case the domain is the same or a sub domain. Should we do the same the other way around and forward response cookies, too, in that case?

[Nickersoft]

So it's not (well, my app is under an app. subdomain and my API is under api.), but I account for this in my hooks.server.ts file, as recommended by the documentation:

export const handleFetch: HandleFetch = async ({ fetch, request, event }) => {
	if (request.url.startsWith(endpoints.api)) {
		request.headers.set('cookie', event.request.headers.get('cookie') ?? '');
	}

	return fetch(request);
};

So my cookies are actually being sent to the API. However, my API is returning with a set-cookie header, which the server-side fetch ignores, not setting my access tokens on my browser. I tried accounting for this with something like this:

export const handleFetch: HandleFetch = async ({ fetch, request, event }) => {
	if (request.url.startsWith(endpoints.api)) {
		request.headers.set('cookie', event.request.headers.get('cookie') ?? '');
	}

	const res = await fetch(request);
	
	event.setHeaders({ cookie: res.headers.get('set-cookie') ?? '' });

	return res;
};

but to no avail. I don't think this function expects you to try using the request response to set data on the event object, only the other way around.

[dummdidumm]

Your idea of passing them along is almost right, but:

• the header is called set-cookie, not cookie (mistake in setHeaders)
• you can't set cookies through setHeaders, use cookies for that: event.cookies.set('name', 'value', options). To parse the cookie you can either use https://www.npmjs.com/package/set-cookie-parser or https://www.npmjs.com/package/cookie

Doing this should work as expected - therefore closing this.

[Nickersoft]

Hey @dummdidumm! Sorry for the delay in circling back to this – I updated my code, but cookies still aren't being set sadly :/

import { endpoints } from '$lib/constants';
import type { Handle, HandleFetch } from '@sveltejs/kit';
import type { CookieSerializeOptions } from 'cookie';
import scp from 'set-cookie-parser';

export const handleFetch: HandleFetch = async ({ fetch, request, event }) => {
	if (request.url.startsWith(endpoints.api)) {
		request.headers.set('cookie', event.request.headers.get('cookie') ?? '');
	}

	const res = await fetch(request);
	const setCookie = res.headers.get('set-cookie');

	if (setCookie) {
		const parsed = scp.parse(setCookie);

		parsed.forEach((cookie) => {
			event.cookies.set(cookie.name, cookie.value, {
				...cookie,
				sameSite: cookie.sameSite as CookieSerializeOptions['sameSite']
			});
		});
	}

	console.log(event.cookies.get('access_token'));

	return res;
};

The log statement actually prints out the correct value in my server log, but on the client the new cookie value never gets set. Is that intentional?

[dummdidumm]

Have you tried setting a dummy cookie like event.cookies.set('foo', 'bar', { path: '/' }) to rule out it's any specific cookie option that prevents them from being forwarded?

[Nickersoft]

@dummdidumm Yep! So I dug into this anymore, and after being baffled as to why cookies were being set on my repro repo but not in my app, I realized: for some reason, cookies won't be set on hosts other than localhost.

To reproduce in the repo I linked above:

1. Change localhost to yourdomain.com on line 4 and line 8 of server.js.
2. Modify the hooks.server.ts file to set the cookie on yourdomain.com.
3. In your /etc/hosts file, add 127.0.0.1 yourdomain.com and save it with sudo.
4. Start the Svelte server with pnpm dev --host=yourdomain.com.

Loading the page won't set the cookie.

I unfortunately need to use a host alias like this for my app to circumvent my API's CORS restrictions.

[dummdidumm]

This all sounds more related to how browsers handle cookies and their various options which restrict where they are applied (domain, same-site, path, strict, etc), and not related to a SvelteKit issue.
I would suggest to tinker around with your cookie forwarding, leaving out all options first and adding them back one by one until you know which one is responsible for the cookie not showing up. It might also help to set the options to the most insecure configuration possible first, to see if that has any effect.

[Nickersoft]

So I tried it by setting just a basic cookie inside hooks.server.ts which still does not get set on the client, despite getting logged on the server via event.cookies.get('dummy'). I added a button to my repro which calls the same API via a client side fetch, and the cookie is set properly, so it seems to be an issue with how event cookies are set inside handleFetch as far as I can tell when using alternative hosts.

If you follow the reproduction steps you should be able to see it.

[Nickersoft]

Wow! So I actually found the issue here. As it turns out, SvelteKit sets secure to true by default if the origin URL is not localhost. So in order to force the cookie to be set during dev, I need to set secure manually:

import { dev } from '$app/environment';

export const handleFetch: HandleFetch = async ({ fetch, request, event }) => {
	const res = await fetch(request);
	const setCookie = res.headers.get('set-cookie');

	if (setCookie) {
		const parsed = scp.parse(setCookie);

		parsed.forEach((cookie) => {
			event.cookies.set(cookie.name, cookie.value, {
				secure: !dev, // This line is needed
				...cookie,
				sameSite: cookie.sameSite as CookieSerializeOptions['sameSite']
			});
		});
	}
}

Not sure if this is surfaced at all in the docs, but it feels like a gotcha, as I had to dig through the source to learn this lol.