Handling redirects "thrown" from endpoint code.

[cdcarson]

Describe the problem

AFAICT, there's no simple way that one can implement an "authentication gate" (e.g. something that checks for a signed-in user, and if one does not exist, redirects to a sign in page) without explicitly returning the redirect and it's associated headers "inline." By "inline" I mean like this...

// some route where the user has to be authenticated...
export const get = (event) => {
  const currentUser = myGetTheCurrentUser(event);
  if (!currentUser) {
    return {
      status: StatusCodes.MOVED_TEMPORARILY,
      headers: {
        Location: '/auth',
        // plus some cookies to make the redirect user friendly: flash message, original url,  etc.
      }
    };
  } 
  // the user is logged in, so continue...
}

This may not look so bad in one endpoint, but it's not great repeated in every similarly gated endpoint in an app, especially if you want to add some cookies to make the redirect user-friendly.

It'd be way more fun to write it this way...

// some route where the user has to be authenticated...
export const get = (event) => {
  const currentUser = myGateAuthenticated(event);
  // the user is logged in, so continue...
}

... where myGateAuthenticated either returns the user or throws the redirect output (or something that is turned into a redirect output.)

For this to work SvelteKit would have to (slightly?) change the way it deals with the things thrown from endpoints.

Describe the proposed solution

Here's how it'd work...

• SvelteKit wraps the endpoint function in a try...catch block. I'm pretty sure this already happens. :)
• In the catch, if the thrown thing looks like a "redirect output", i.e. an object that has a 3xx status and a Location header, SvelteKit should deal with it just as if had been returned rather than thrown, rather than displaying __error.svelte.

I believe this "authentication redirect" case is pretty special. Other userland conditions where one might want to throw rather than return (e.g. authorization, not found, etc) can be handled by throwing a regular Error and displaying the message in __error.svelte.

It's also a pretty common pattern, and therefore (barring me having missed something obvious) deserves a specific solution.

Alternatives considered

Some things I've tried:

• Throwing a custom error and dealing with it in __error.svelte. This doesn't work -- you can't redirect from ErrorLoad. In any case this solution seems janky.
• Wrapping entire endpoints in try...catch blocks that check for this specific case. This works, but it's almost as inconvenient/verbose as the original situation.

Let me know if I've missed something. Thanks.

Importance

would make my life easier

Additional Information

No response

[Conduitry]

This is one of the cases that would be addressed by layout endpoints (#4274) and inheritable endpoint middleware (which I can't find an issue for right now, but is on the roadmap).