Proposal: Add Layout Guards

[cdcarson]

tldr; Allow layout.server.js to export a guard function in addition to load. This would decouple business logic (e.g. auth) from from data caching, provide a clearer developer experience and encourage secure practices.

Related issues: #6315, #6731

Current benefits of layout.server.js

• A performant, per-user data cache
• Generated merged types for use in components
• Less 'fetch data' boilerplate in +page.server.js

Disadvantages/Needs Work

• Insecure in some circumstances.
• Requires auth (or other logic) boilerplate in +page.server.js.

In order to cache data the client router must have the power to decide, on its own, whether or not to fetch data from the tree.

But the semantics of the current system may tempt the developer to place important logic in the +layout.server.js tree, leaving leaf nodes unprotected. This is an easy mistake to make:

• Assume that +layout.server.js will be called for every request just like +page.server.js. (It isn't.)
• Think it doesn't really matter. (It does. Cookies expire. Permissions stored in a database change.)
• Assume client-side cache invalidation is enough to force server-side logic to be run. (I'm pretty sure it's not -- it seems pretty hackable.)

My current way around this is to secure each route as necessary in +page.server.js, which always runs. This is reasonable, and it may be better to simply say this is the correct approach, rather than adding a feature to the API. But I think that would throw a couple of babies (caching, less boilerplate) out with the bathwater.

General Considerations

• We need logic on the server to decide what's cacheable and what's not. We can't rely on the client to do that job, either through invalidation or the manifest.
• We should be able to make useful distinctions about caching even when we do force the client to hit the server for auth. For example, checking a cookie is generally quicker than making a database query or an external API call.

Proposed Solution

Each +layout.server.js exports one or both of:

• a load function as it is now.
• a guard function:

export interface LayoutServerGuard<
  Params extends Partial<Record<string, string>> = Partial<
    Record<string, string>
  >
> {
  (event: RequestEvent<Params>): MaybePromise<void>;
}

Some notes about this:

• We treat a guard + load pair (i.e., appearing in the same +layout.server.js) as a unit. Within that unit guard runs before load, in series. But many of these pairs can be run concurrently, just as many loads are now.
• Unlike load, guard isn't part of a tree. It only applies to its layout node.
• guard, if present, runs on every request the layout node applies to.
• load, as now, runs on the first request and after cache invalidation.
• guard takes only a RequestEvent, and returns void. This is deliberate, to decouple it from data collection and caching.
• The rules for when guard runs are enforced on the server. The only thing the client router has to know is whether a particular layout node is guarded or not, so it can decide what needs to be re-fetched.
• Importantly for caching, such a re-fetch would not automatically mean that the associated load gets run. This would only happen if the node had been invalidated.

Here's a chart:

+layout.server.js exports...	First Request	Every Request	Request After Cache Invalidation
guard + load	guard runs, then load runs	guard runs	guard runs, then load runs
guard only	guard runs	guard runs	guard runs
load only	load runs	-	load runs

DX Benefits

• The guard export is entirely optional. I think it would be a non-breaking change.
• It's clear what's going on. The concerns of caching and auth are separated. It's easy to explain.

Other Options

• An event.alwaysRun() flag that one would call in load. Described here.
• hooks.server.js Add support for per-directory +hooks.server.js route files #6731

---

I'm pretty sure that guard is doable without too much work (famous last words.) Anyway let me know what you think and thanks for reading!

[williamviktorsson]

Highly in support as it feels like a very natural place to handle authorization together with layout groups. Either this or layout group wide hooks with the already discussed event.alwaysRun() discussed elsewhere.

[dummdidumm]

Throwing my quick thought into here:

A different way to tackle this could be to tell a load function to

• a) always run no matter what
• b) not rerun, i.e. reuse the old value

import { ignore } from "@sveltejs/kit";

export function load({ changes, depends }) {
  depends(true); // always rerun
  if (changes.url) { // called due to url change
     throw ignore(); // skip this load function, signal to reuse the old version
  }
  // ..
}

[cdcarson]

Repeating back (tell me if this is what you mean)...

• depends would set a flag for the layout path on the server. The flag would mean that the layout load would always be called (first, synchronously) when a child layout/page load was called. That is, the logic is enforced on the server, not by the CSR.
• The developer would determine inside the load whether to refetch data from the database or wherever.
• If not, the load would tell the client to use the cached data.

To expand on your example...

// src/routes/dashboard/[id]/+layout.server.ts
import { ignore } from "@sveltejs/kit";

export const load = async (event): Promise<{stats: ExpensivelyFetchedDashboardStats}> {
  depends(true); // always rerun

  // Checks the user's permissions for the dashboard `id`.
  // Maybe as quick as reading a cookie, maybe not. 
  await gateDashboard(event);

  if (event.changes.url) { // called due to url change
     throw ignore(); // skip this load function, signal to reuse the old version
  }
  return {
    stats: await fetchDashboardStatsExpensivelyFromDatabase(params.id)
  }
}

I love it. It takes care of the security hiccup, maintains cache efficiency, and doesn't require a separate function/file.

[dummdidumm]

Yeah that's what I meant, thanks for clarifying 👍

[williamviktorsson]

Is there a current workaround where one could somewhat achieve this? 🤞

[cdcarson]

Is there a current workaround where one could somewhat achieve this?

@williamviktorsson I think the only option right now is to protect each route in +page.server.ts. This is OK, but there are situations where it'd be nice just to set it and forget it in +layout.server.ts

[williamviktorsson]

It feels like I could also create this behavior through auth logic in the hooks.server.js handle function.

Perhaps an enhancement which would aid in writing the handle function would be to expose what layout groups/layouts are being accessed for a specific request.

this would allow writing something like this in the handle function:

if(request.route.groups.contains(”auth”){
    handleGuard(request);
}

or something like:

if(request.route.layouts.auth){
    handleGuard(request);
}

Would it make sense to provide something like this even if the decision is made to go forward with either the runAlways() functionality in layout loads, a layout guard function or route specific hooks.server.js, which all seem like promising suggestions to facilitate route guards? 🤔

[danielimmke]

I agree we should have something like guard - but there are going to be some instances where you don't want to run load() again on a +page.server OR +layout.server

For example, if you have query parameters for sorting data and pagination, but you don't want to rerun the DB query inside of load - only if they select a condition that requires you to widen the scope of your query.

Guard would work in this scenario - but in a different way. The same way Svelte has invalidate methods - it would be the inverse. Basically saying "Don't run load()" again for this page or layout. The key difference is that in my scenario load has already been run once and returned data.

To get around this in a situation where some search params changing needed a new DB call and some didn't (they all invalidate and cause load to rerun), I had to store the result of my load function as a memoized variable and "short circuit" to prevent calling the DB again. Without that memoization - I can't end load early because I have no way of persisting the data that's already there from the last load.

I'd love it if we could figure out a way to address both of these needs.

interface ExploreParams {
  tags?: string;
  status?: string;
  page?: number;
  sort?: string;
}

let urlParams: ExploreParams;

let memoizedResult: any = null;

const triggerReload = ['tags', 'status']

const preventLoad = (url: URL): boolean => {
  if(url.search === '') return false
  if(memoizedResult === null) return false;

  for (const key of url.searchParams.keys()) {
    if(triggerReload.includes(key)) {
      if(urlParams[key] === undefined) return false;
      if(urlParams[key] !== url.searchParams.get(key)) return false;
    }
  }

  return true;
}

export const load = (async ({ url } : {url: URL}) => {
  if(preventLoad(url)) return memoizedResult;

  if(url.search && urlParams === undefined) urlParams = Object.fromEntries(url.searchParams)

  // ...Database Query ...

  let result = {
    meta: {
      title: 'Title',
      description: 'Page description'
    },
    tags,
    results
  }

  memoizedResult = result; // saves a copy every time a new result is generated
  return result;
}) satisfies PageServerLoad;

[dummdidumm]

This is tracked in #6294