I feel like I asked this earlier. 🤔 (If I did, sorry. 😩) Is there an easy way to replicate the middleware logic that SuperTokens requires? On an express server, I'm seeing that mainly 4 things are needed: 1)

SuperTokens.init

(once) 2)

cors

middleware 3) SuperTokens middleware 4) SuperTokens error handling middleware The reason I ask is that as more SSR frameworks come out (e.g., SolidStart, SvelteKit, etc.), I'm realizing that a lot of tools -- even some of Auth0's tools -- are restricted by the fact that they're expecting to be run directly on some kind of server (e.g., an express server). Of course, they are running on some kind of server. But the SSR frameworks try to abstract all of that away. This makes it hard (if not impossible) to apply the security logic which SuperTokens applies. These frameworks have "middleware-like" logic that can be supplied, but oftentimes this is incompatible with "real middleware". Obviously this has been a problem for other similar auth options so far. But if SuperTokens were able to provide a way to integrate with these frameworks universally (or maybe a way can already be found from the codebase), it would have an edge on the other options -- at least as far as the crazy JS ecosystem is concerned.

hey @ITEnthusiasm what are the differences in terms of a middleware for these SSR based frameworks vs regular api servers?

Probably the most consistent thing is that there's no one simple

app.use

-like logic to create a middleware chain. Svelte Kit has

handle

(https://kit.svelte.dev/docs/hooks#server-hooks), which gives people the opportunity to do something with a request before server rendering the page. But that means any logic (e.g., SuperTokens middleware) has to be placed within the

handle

function (directly, or indirectly via functions), which means insights would be needed on what the SuperTokens middleware is trying to do. The request information is also a bit different since it's in the form of a "RequestEvent" (https://kit.svelte.dev/docs/types#sveltejs-kit-requestevent). Solid.js similarly has a

createHandler

utility (https://start.solidjs.com/api/entry-server#createhandlermiddlewarefn). It seems this utility is only intended to be used once. It also exposes request information within some kind of "event" (a "PageEvent"). So again, any logic that would have come from

app.use(middleware)

now has to be put within the function itself. Technically speaking, other tools like Next.js are like this. But I'm assuming tools like Auth0 just work around this by using their knowledge of some of the details about Next.js's backend... and then they export something through a package. It's only worthwhile to go through that effort because Next.js is so big.

hm. Could you please open an issue about this highlighting the above details? And we can have a look at it soonish

Sure! I'll open one later today. I have to run off somewhere soon 😅

thank you!