Astro SSR middleware

[thepassle]

I was trying to figure out if there was any way to have route handlers act as 'middleware' of sorts, but I couldn't find anything.

Usecase

Maybe I have some static assets that I'd like to only make available for logged in users, e.g.:

/protected/[...a]/index.js:

export async function get(_, request) {
  const auth = isLoggedIn();

  const url = new URL(request.url);
  const protectedRoutes = new URLPattern({pathname: '/protected/images/:image'});
  const match = protectedRoutes.exec(url);

  // This is a 'protected' asset
  if(match) {
    if(auth) {
      // If user is authenticated, continue the request
      return fetch(request);
    } else {
      // If user is not authenticated, forbidden
      return new Response(null, {status: 403});
    }
  }
  
  // request didnt match any protected assets, pass it on as normal
  return fetch(request);
}

request (user is logged in):
/protected/my-img.png -> 200

request (user is not logged in):
/protected/my-img.png -> 403

Like for example in a service worker you would be able to just forward the request like:

self.addEventListener('fetch', e => {
  e.respondWith(fetch(e.request));
});

Most of all it would be really nice to just be able to forward a request by either calling a next() function, or just returning fetch(request), e.g.:

export function myAuthMiddleware(_, request, next) {
  if(auth) return next();
  return new Response(null, {status: 403});
}

Alternative syntax for middleware could be instead of exporting a get function, exporting a get array:
/my-route.js:

export const get = [
  authMiddleware,
  async (_, request) => return new Response(null, {status: 200});
];

or even returning an array from the function:

export function get() {
  return [
    authMiddleWare,
    async (_, request) => return new Response(null, {status: 200});
  ]
}

[thepassle]

By coincidence, I noticed this commit:

Which made me think if those checks would be reversed, e.g.:

if (app.match(request)) {
  return app.render(request);
}
if (manifest.assets.has(url.pathname)) {
  return;
}

That would potentially give us a chance to react to an asset request, e.g.:

/protected/[...all]/index.js:

export async function get(_, request) {
  const auth = isLoggedIn();

  const url = new URL(request.url);
  const protectedRoutes = new URLPattern({pathname: '/protected/images/:image'});
  const match = protectedRoutes.exec(url);

  if(match) {
    if(auth) {
      return;
    } else {
      return new Response(null, {status: 403});
    }
  }
  
  return;
}

[jamesarosen]

What's the first argument to get here? In all your examples you label it _. Is it Astro? Some sort of Context?

[zicklag]

I've got a scenario where I have an SSR site with multilingual support where you can visit the site with either a /en prefix or a /fr prefix, etc.

But if you visit the site with a prefix that isn't support, it should redirect to the default language, /en. I want to do this for every single page, which requires me to put this at the top of all of my pages in the frontmatter:

const redir = localization.initLang(Astro);
if (redir) {
  return redir;
}

My localization.initLang() function will return a redirect response to the default langage if the language doesn't exist. This is fine, but I don't want to have to remember to place this code at the top of every one of my page's frontmatter.

It would be great if I could add a middleware that would allow me to add this logic to every page automatically.

[skreutzberger]

Middleware would be also a solution for my current issue: I want to set my own cache-control header values to the response of a page like index.astro.

[nowaythatworked]

Not a solution for the middleware but you can set response headers via the global Astro object:
Astro.response.headers.append('Cache-Control', 's-maxage=10')

[jamesarosen]

That works great for pages, but has two shortcomings:

• it doesn't (currently) work in Layouts, so every page has to do it individually
• it doesn't work for static assets, so there's no way to define a cache-control or CORS headers for static assets. (Some hosting providers have configuration for this, but it's inconsistent)

[pilcrowonpaper]

I would love something like SvelteKit's hooks.

1. You can modify responses from API routes and pages after SSR
2. You can share data between middleware (hooks) and the request handler (loaders and API routes)

A simple hooks look something like this:

export const handle = async ({ event, resolve }) => {
  const response = await resolve(event);
  return response;
}

The handle function will be called on every request. The parameter event is equivalent to Astro's Astro global and holds things like the request and url, and is available in API routes and load functions (loaders in Remix, getServerSideProps in Next). await resolve(event) is where SvelteKit resolves your API routes and pages, and returns the response from it. You can then return that response to send it back to the user. Of course, instead of the response from resolve(), you can return your own response to redirect users, etc.

One thing super useful is event.locals. It's a regular object that you can add anything to it. This object is available inside load functions and API routes, allowing to share data between hooks and pages. A common use case for it is to storing the user's session:

export const handle = async ({ event, resolve }) => {
  event.locals.session = await getSessionFromRequest(event.request);
  const response = await resolve(event); // event.locals.session available in route handler
  return response;
}

You can even add functions to it, allowing to create functions that read and modify the request and response without passing on the event object.

Though the simplicity kinda falls apart when you have multiple handle function. You can use a helper called sequence but the order it executes is kinda weird: https://kit.svelte.dev/docs/modules#sveltejs-kit-hooks-sequence

This is might be a deal breaker if you want have community supported middleware, like Express.

tldr; It'd be great if you can set headers and cookies in middleware, as well as share data between middleware and .astro files.

[jamesarosen]

SvelteKit's hooks are a great example! There are a few other "standard" APIs for middleware in JavaScript that would also make good candidates for this API:

// express.use
function (req, res, next?, err?)

// middie.run
function (err?, req, res, ctx)

// ServiceWorkers / Cloudflare / Fastly
FetchEvent({ request: Request }) => Response

[matthewp]

I think it would be great to tackle middleware. I think what we really need is a good list of goals / non-goals. One particular goal I think we should shoot for is having the middleware work in both dev and prod, no matter which adapter you are using. Some past proposals have not done this, they were prod only.

Another thing I think we need here before we start picking a specific API is a comparison between other frameworks and how they solve this issue.

[pilcrowonpaper]

One important thing I forgot to add to my comment about SvelteKit's implementation. SvelteKit's hooks runs during server-side rendering and on pre-rendering, since it's just part of the rendering process. Whatever the implementation we end up with, I think it should be adapter-independent and work both in SSG and SSR.

[bholmesdev]

Thanks for presenting this one back in the day @thepassle! The Astro team recently moved rfcs to this new roadmap repo to better track pre-RFC discussions and proposals. You can find our new public roadmap here.

I'm curious if you'd want to lead a proposal on this idea with more details fleshed out? There's definitely interest in the idea, but we'd love to have a community champion to start shaping goals and updated usage examples (see our new proposal template here). If you're interested, feel free to update the discussion based on the new template. You can share around the discord for feedback or input as well!

[thepassle]

I think middleware would still be a great feature for Astro! I dont think I currently have the time to commit to driving this proposal unfortunately, so if anybody else wants to pick this up, feel free!

[pilcrowonpaper]

@thepassle I'd love to work on this idea! Will create a proposal, if you don't mind.

[pilcrowonpaper]

Hm, ok some issues. Astro is built upon the standard Response object. This makes implementing an Express like sequence based middleware really hard, specifically how cookies/setHeaders() work. Kinda understand why SvelteKit went with their implementation. Might take a while!

[pilcrowonpaper]

Done: #469

[matthewp]

Middleware has been accepted and has moved to stage 2 (based on @pilcrowonpaper's new proposal): #531

[thepassle]

Sweet :)