Provide a way to opt-out middlewares from running at SSG

[danielo515]

Body

Here we go again...

Summary

I want to be able to opt out of middlewares running at build step (SSG phase)

Background & Motivation

I use middlewares to do both authentication and authorization, which does not make sense for static pages, so in the best case they are just overhead, and in the worst they prevent some pages from being properly rendered.

Goals

• I would love to have a mechanism to opt out from middleware executiong during build phase
• Ideally being able to decide which ones to run by exporting some env variable like process.env.SSG or something like that so I can decide in the middleware based on that.

Example

Something like I already mentioned import.meta.env.SSG

[ematipico]

@danielo515 please fill the template

[danielo515]

WTF? I filled the template, don't understand how did it ended like that

[Fryuni]

Just found this. It is already possible to differentiate between those stages, but it is not intuitive if you are unfamiliar with Astro details (maybe even some internals).

So, I just published that as an integration to make it easy to use: https://inox-tools.vercel.app/astro-when

Specifically, you might want to look at the middleware example: https://github.com/Fryuni/inox-tools/blob/main/examples/astro-when/src/middleware.ts

---

This is not to say that this won't be available as a higher-level API part of Astro, nor that it will. I'm just providing a wrapper on how it is already currently possible with the lower-level APIs. The integration above should continue to work even if Astro gets its own API for it.

[IndependentCreator]

Related - I've configured my (Astro 4.10.1) project with output mode server and my middleware.ts file code is checking context.request.headers. When I configure a specifc astro page with export const prerender = true; I see this warning in the terminal at runtime:

[WARN] `Astro.request.headers` is unavailable in "static" output mode, and in prerendered pages within "hybrid" and "server" output modes. If you need access to request headers, make sure that `output` is configured as either `"server"` or `output: "hybrid"` in your config file, and that the page accessing the headers is rendered on-demand.

[IndependentCreator]

Thanks for your help. In my case, this line from middleware.ts triggers the warnings for prerender = true pages:
const sessionId = context.cookies.get( "mycookiename" );

I'm trying to follow a pattern recommended by lucia-auth: checking for a session cookie in middleware.ts, retrieving the corresponding session and user from the database, and saving the session and user variables in Astro.locals so that I can access them from the prerender = false pages.

I was thinking that some pages won't need session information and therefore they could be set to prerender = true, but that triggers the warnings. I'm open to suggestions if there's a pattern better suited to doing this in Astro.

[ematipico]

If you think about it, if you don't need session information, hence const sessionId = context.cookies.get( "mycookiename" ) isn't needed.

[IndependentCreator]

Yes, but if I add const sessionId = context.cookies.get( "mycookiename" ) to middleware.ts, it gets run for every page, even the (prerender = true) ones where it doesn't function and it isn't needed, correct?

So the only ways to avoid the warning would be A) use prerender = false for all pages, regardless of whether they need session information, or B) Only call const sessionId = context.cookies.get( "mycookiename" ) from prerender = false pages (instead of calling it from middleware.ts). Am I understanding correctly?

[ematipico]

Oooh, I see! That makes sense now! I'll think about it

[IndependentCreator]

In the future it might be nice to have 2 separate hooks, e.g. defineMiddlewarePrerenderTrue() and defineMiddlewarePrerenderFalse()

In my case I have refactored my code so that all of the session cookie retrieval happens inside my SessionData class. For my specific situation this is probably more natural, because the SessionData class was already needed for precisely those pages that require session access 🙂

[danielo515]

Yes, but the middleware running is the unexpected thing El mar, 11 jun 2024, 15:42, Emanuele Stoppa ***@***.***> escribió:

…

That's expected. Prerendered pages will be built, and they will become HTML pages, so it's expected that you won't have access to Astro.request.headers. — Reply to this email directly, view it on GitHub <#867 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARKJWMNAW4GKVOUN635WBDZG35DJAVCNFSM6AAAAABE5B6FX6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMZZGUZTA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ematipico]

I am sure you come from a different background, so I understand what you mean. However, we document its behaviour in the documentation, so there's no unexpected things: https://docs.astro.build/en/guides/middleware/

Middleware allows you to intercept requests and responses and inject behaviors dynamically every time a page or endpoint is about to be rendered. This rendering occurs at build time for all prerendered pages, but occurs when the route is requested for pages rendered on demand.

[danielo515]

Just to be sure I understand, can someone explain me what is the use case for a middleware running in static generation? They are inherently dynamic to me El mié, 12 jun 2024, 12:39, Emanuele Stoppa ***@***.***> escribió:

…

Oooh, I see! That makes sense now! I'll think about it — Reply to this email directly, view it on GitHub <#867 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARKJWMUBKMGMHRPFNWPA6LZHAQO5AVCNFSM6AAAAABE5B6FX6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TONJQGE3DE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Fryuni]

Things like redacting, authenticating server-side tools that are per page, any shared logic between routes, populating the Astro.locals with information that needs to be accessible by components deep in the page without prop drilling, etc.