How to build a JWT-based session system when you can’t set cookies in a query function?

[Asguho]

I have a JWT session system using long-lived and short-lived tokens. I’m making a request to a query function, but the short-lived token has expired. My logic is to use the long-lived token to verify the user in the DB, return the requested data, and ideally send back a new short-lived token as a cookie to save a DB trip on the next few requests.

However, I’m getting an error: Error: Cannot set cookies in query or prerender functions. Since this is my first time implementing JWT sessions from scratch, am I doing something wrong, or is there a workaround? Also, why does this limitation exist? It feels arbitrary, but I assume it’s for cacheability, though I wouldn't want these requests cached anyway, as they’d return stale data.

[edwardmanhattan]

would be nice if someone gives an insight about this

[wesleysmyth]

The restriction exists because SvelteKit's load functions (query functions) can run in parallel, be cached, and must produce deterministic results. Setting cookies as a side effect of loading data would break these guarantees — for example, if two load functions try to set the same cookie, the result is a race condition.

The solution: Move token refresh to hooks.server.ts

The handle hook runs once per request, before any load function, and has full access to cookies. This is the right place for JWT refresh logic:

// src/hooks.server.ts
import type { Handle } from '@sveltejs/kit';

export const handle: Handle = async ({ event, resolve }) => {
  const accessToken = event.cookies.get('access_token');
  const refreshToken = event.cookies.get('refresh_token');

  if (!accessToken && refreshToken) {
    // Short-lived token expired, use refresh token
    const response = await fetch('https://your-api.com/auth/refresh', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ token: refreshToken }),
    });

    if (response.ok) {
      const { access_token, refresh_token } = await response.json();

      event.cookies.set('access_token', access_token, {
        path: '/',
        httpOnly: true,
        secure: true,
        sameSite: 'strict',
        maxAge: 60 * 15, // 15 minutes
      });

      if (refresh_token) {
        event.cookies.set('refresh_token', refresh_token, {
          path: '/',
          httpOnly: true,
          secure: true,
          sameSite: 'strict',
          maxAge: 60 * 60 * 24 * 7, // 7 days
        });
      }
    }
  }

  // Make the user available to all load functions via locals
  if (event.cookies.get('access_token')) {
    event.locals.user = decodeJwt(event.cookies.get('access_token')!);
  }

  return resolve(event);
};

Now your load functions just read from event.locals — no cookie manipulation needed:

// +page.server.ts
export const load = async ({ locals }) => {
  if (!locals.user) throw redirect(303, '/login');
  return { user: locals.user };
};

This way the refresh happens transparently on every request, and your load functions stay pure data-fetching functions.

[SX110903]

si el problema es que no puedes setear cookies en query functions, la solucion es mover esa logica a un hook. en hooks.server.ts puedes interceptar la request, verificar el token corto, si expiro usar el largo para renovarlo y setear la cookie ahi antes de que llegue a la query.

// hooks.server.ts
export const handle = async ({ event, resolve }) => {
  const shortToken = event.cookies.get("short_token")
  
  if (isExpired(shortToken)) {
    const longToken = event.cookies.get("long_token")
    if (isValid(longToken)) {
      const newShort = generateShortToken(longToken)
      event.cookies.set("short_token", newShort, { path: "/" })
    }
  }
  
  return resolve(event)
}

la restriccion existe porque las query functions pueden ejecutarse en contextos donde no hay una response HTTP activa (prerender, etc). los hooks si tienen acceso completo a la response. es un poco lio al principio pero tiene su logica