Implementing safe & secure file-based stores

[AlbertMarashi]

Hi everyone,

I have implemented a Draft PR prototype that implements request-level store isolation during server-side rendering using node's AsyncLocalStorage functionality which enables the ability to provide different global contexts to code running within isolated async functions (as is done in the server response generation code)

#12215

Would love to get your feedback and finally solve this important issue

Old Approach

Current Issue

Using Stores in SvelteKit requires you to initialize them during a request entry (currently done via the load functions in SvelteKit)

This creates a few problems

• The "file-based" stores that work in Svelte / Client-side can't be used in SSR because they leak state across requests, a major security vulnerability if improperly used.
• This as a result completely changes the ergonomics of using stores, and complicates them because we have to pass them around across the app via Contexts or declare them globally in root layouts, and include them in the app.d.ts PageData to ensure they are accurately typed, if we want to access them via the $page store.
• Additionally, these stores cannot be used in normal typescript files as they do not have access to the context of Svelte Components

This seems like the most complained about issue in SvelteKit, according to upvotes of #4339 and #6098

Proposed Solution

I propose a solution of creating a Safe Stores and safe variables by isolating the stores across requests, enabling file-based stores to exist, and additionally enabling normal typescript files to be able to import them.

Benefits

• allows file-based stores to be used, like in Svelte docs
• safe & secure from cross-request contamination of data
• clean, simple and ergonomic use of stores by simply importing them
• allows typescript/javascript files to import stores, without side effects

Modifications to svelte

Transforming build modules into async functions

Say we have the following code:

import Foo from "./Foo.js"
let x = 1

export async function load() {
  x++
  return {
    x,
    foo: Foo.bar
  }
}

will be transformed into something that looks like this at compile/build-time (simplified):

export default async function(global, ssrImportMeta, ssrDynamicImport, ssrExport) {
  const Foo = await ssrDynamicImport("./Foo.js")

  let x = 1

  ssrExport.load = async function load() {
    x++
    return {
      x, // this will always be 2, even across requests
      foo: Foo.bar
    }
  }
}

This is done by parsing the compiled output, and walking the AST tree to find instances of import/export & etc. (most of the code for this already exists in Vite and can be adapted see: ssrTransform.ts)

Pseudocode implementation

This would be the located somewhere in the respond.js file

// start of a request
let initialized_modules = new Map()
let request_global = { ...global, request_stores: new Map() }
request_global.global = request_global
// if we want access to the real global
request_global.__real_global = global

async function ssrDynamicImport(uri: string): object/export {
   if (!initialized_modules.has(uri) {
       let ssrImportMeta = // parse the URI for meta/query (?) fields
       let uninitialized_module = await import(uri) // normal import of the transformed module from the manifest
       let ssrExport = new Promise(resolve => {
          let ssrExport = {}
          await imported_module(request_global, ssrImportMeta, ssrDynamicImport, ssrExport)
          return ssrExport
       })
       initialized_modules.set(ssrExport)
    }
    return await initialized_modules.get(uri)
}

let ssr_entry_point = await ssrDynamicImport("ssr-entry.js")

// do whatever we do already here as normal

How it works

universal_writable.ts

export interface Writable<T> {
    subscribe(callback: (data: T) => void): void
    update(data: T): void
}

// use name to uniquely identify a store, so it can be passed to client
// and client can reinitialize store from SSR data
// function name should somehow reflect that the store is passed to client & universal
export default function universal_writeable<T>(name: string, data: T): Writable<T> {
    // global or window depending on if we are running on SSR or Client-side
    let store = global.request_stores.get(name)
    if (!store) {
       // create the store as normal
       // add to request_stores and assign to store variable
    }
    
    return store
}

Using it would work like so:

user_store.ts

import universal_writable from "./universal_writable"

export type User {
    name: string
}

export const user_store = universal_writable<User|null>("user", null)

+layout.ts

import user_store from "./user_store"

export async function load () {
    const user = your_api.get_user()
    user_store.update(user)
    return {}
}

+page.svelte

<script lang="ts">
import user_store from './user_store'

// works in both SSR & Client-side with no cross-request contamination
// data is hydrated/passed into client-side from SSR
$: user = $user_store

</script>

{ #if $user }
    <p>Hello {$user.name}</p>
{/if}

I think this solution would significantly improve the experience of developing with svelte, reduce the learning curve, and provide clean and ergonomic access to stores.

[AlbertMarashi]

@Rich-Harris @dummdidumm this solves this issue #5231

EDIT
I have significantly altered this proposal, so the following comments no longer apply/out of date

• Implementing safe & secure file-based stores #9878 (comment)
• Implementing safe & secure file-based stores #9878 (comment)
• Implementing safe & secure file-based stores #9878 (comment)

[dummdidumm]

I don't understand how this would safely determine which store instance belongs to which request, and how it would prevent memory leaks since the store is never unloaded.

[lxhom]

[outdated: the proposal was changed!]

I still think there is an issue with this approach: At some point a copy of a store is neccesary. Copying is hard, because sometimes we need a reference to it, but sometimes a clone to it. Two examples (that I have stumbled upon) to show what I mean:

1. Cloning neccesary

When storing/modifying an object with multiple sub-objects, a clone would be neccesary:

// stores.js
export let settings = writable({sound: {volume: 100}})
// component.svelte
$settings.sound.volume = 100

If a reference to the objects is passed here, the state will be globally shared.

2. Reference neccesary

I recently worked on a small i18n library based on JS objects. I used a placeholder proxy to get placeholders while it is loading a new language:

let lang = writable(placeholderProxy)
let loadLanguage = code => lang.set(getLanguage(code))
console.assert(lang.this.property.doesnt.exist.but.the.proxy.fills.it.in)

Cloning that would make that proxy break.

And the other problem is references to other stores. For example, in my i18n library I have two connected stores:

export let lang = writable({hello: 'Hello World'})
export let langCode = writable('en')
langCode.subscribe(code => lang.set(getLang(code)))

Isolating those references seems pretty hard, and I think that the best solution is to give the users the choice. I'm implementing a small workaround library and using it on a few projects to get end-user experience, and I've come to the conclusion that the best way is to provide three options:

• Clone the original value
• Keep the reference to the original value
• Use a provided store factory

I thought about this the last few days and I think the mentioned edge cases can only be solved by either using VMs or giving the users this choice, but if you know how to fix those issues LMK!

[AlbertMarashi]

Please note that the safe_writable function takes in a function that returns T, it does not take in T so that the value is always copied, and safe.

This ensures that a new copy of data is provided to each request's store.

Alternatively, instead of a callback that returns T we could also deeply clone the object in order to maintain the signature of writable but this specific solution suggests creating a safe_writable type of store with a different signature.

Regarding the VM I was the one who suggested this approach, however looking at Vites code, it appears as if it can be done without a VM

[lxhom]

Oh yep, I completely overlooked that. That would solve it.

[lxhom]

[outdated: the proposal was changed!]

Also, correct me if I'm wrong but wouldn't this break with async requests? In a 100% sync context it should work, but if two requests get SSR'd at the same time, global.__svelte_request_stores would need to have two separate values at the same time. Or does Vite resolve global somehow else? I'm not super familiar with Vite, but this seems like it would break

[lxhom]

Are you sure that it's different? I made a rough mockup and managed to leak a variable via global from two separate browser profiles, both with JS deactivated to see the SSR result

[AlbertMarashi]

No sorry to clarify, it's not different currently, but in the proposal of changes it would modify Vite to provide a unique global context. Currently that is not the case

[lxhom]

Oh, yep, got it. That actually seems like a feasible idea

[lxhom]

Excuse my probably stupid question, but how exactly would you get the request data into the global variant? If we modify it to include a function or getter to a request context, how exactly do we get that request context? We need to pass the request (or a context in it) down to ssrModuleLoader.ts, and unless you somehow manage to get getContext/setContext working in pure JS¹ I don't see how you would pass the context to that function. (I guess you could do it similar to the way I do it in the screenshot above by calling a function in each component)

Footnotes

1. This is actually somewhat doable by abusing stack traces and creating functions with eval(), but it's a giant hack and should not be done. ↩

[AlbertMarashi]

@lxhom I have significantly altered the proposal so it might be appropriate to delete/edit your comments as it may confuse people reading this

I learnt that vite is not actually used in production, so the whole old proposal was based on a flawed assumption

[samardzicneo]

@AlbertMarashi Not sure if you're familiar with NodeJS' AsyncLocalStorage but I imagine it'd make your solution simpler by avoiding the need to wrap everything in a function.

[david-plugge]

It is a wonderful piece of magic but its also not supported in many environments. Atleast when i checked last time. And its also pretty slow!

[samardzicneo]

From what I can see, it works in Node 16+, as well as recent versions of Deno and Bun. Beyond this, I can't think of any server-side JS frameworks. As for performance, I haven't benchmarked it specifically but in Node v20, a function that relies on this hasn't shown any measurable performance deterioration. This might be different for different versions or runtimes.

[david-plugge]

What about cloudflare and all the other Edge runtimes?

[samardzicneo]

I'm not sure that it's necessary there, don't they serve each request from an isolated process anyways? CF Workers seems to support ALS though, as does Vercel.

[AlbertMarashi]

No, serverless functions can often be shared across multiple requests

[AlbertMarashi]

I've implemented a prototype of this system using AsyncLocalStorage and it's working and isolating the stores on server side.

But because node:async-hooks import isn't available on the client-side, I need to figure out how to import a different module during SSR and use the normal store behaviour on client side.