Make server version of fetch() in load() copy over 'set-cookie' to the page response

Is your feature request related to a problem? Please describe. Currently, the isomorphism of the load() function breaks when a fetch response, from an internal url, contains set-cookie. If it’s called by the client, the cookie is set in the browser, if it’s called by the server, the cookie is dropped.

One use case is to create a session when a guest visits a page that should only be visible to a registered user. This session should record what page to return the guest to, once she registers.

Some people might suggest passing the return url as a query to the register page, but that means we now have to sanitize the url, prevent users from being redirected to external sites, and even if we do this, we still can’t prevent users from being redirected to other irrelevant internal pages (e.g., people register via an url shared online that contains the query to redirect them to an irrelevant page)

Describe the solution you’d like The server’s version of fetch should copy over cookie headers from the fetch response, from an internal url, to the page response, (including a redirect response like 302)

Describe alternatives you’ve considered We can redirect guests to an endpoint that creates the session and return the cookie header, but that forces a page refresh, breaking the SPA experience that svelte kit tries so hard to deliver.

How important is this feature to you? Very, and I think this recording return url use case should be really common.

Additional context None.

[benmccann]

Try changing it to event.request.headers.get('cookie')

[kevinrenskers]

When I was working on my SvelteKit app and Django-based API locally, everything worked fine. When the web app logs in on the API, the API sends back a set-cookie header with the localhost domain, and from then on the web app knows that the user is logged in because we could read the cookie and copy it to the session:

// hooks.js
import cookie from "cookie";

export async function handle({ request, resolve }) {
  const cookies = cookie.parse(request.headers.cookie || "");
  request.locals.token = cookies.token;
  return await resolve(request);
}

export function getSession({ locals }) {
  return {
    token: locals.token,
  };
}

And on every request that’s made to the API server from then on, the cookie containing the token would be sent back, and all was well.

Now I have deployed my project, and I am running into a problem. When www.example.com logs in to the API at api.example.com, the cookie is set with the api.example.com domain. That means that the web app can’t read it, and it doesn’t know if you’re logged in. I can use example.com as the cookie domain with SameSite set to Lax and then the web app can read it and know’s you’re logged in, but then requests made the API won’t have that cookie attached and so they fail. Question one: is this a SvelteKit bug?

I guess I could set the cookie domain to example.com and instead of relying on the credentials: "include" parameter of fetch, always send the token along an an Authorization header. But that is a pretty big refactor, I’d have to change all the places where I am making API requests to send along session.token, so question two: I was really hoping there are better alternatives?