Dangerous Store behavior with SSR

[sjmueller]

Describe the bug

In adopting Svelte for our chat+communities app, we are trying to utilize the Store for our complex state needs. In this process, we came across semantic differences between stores on the client vs the server that are very concerning -- described in detail here: #2213 Using a Svelte store in the load function causes weird behavior

as soon as you create your own store, it becomes global server-side in a SSR context (= your store is a singleton in memory server-side, so it is shared by all HTTP requests hitting your server)

We are coming from react+redux, which also has the concept of a store where you would keep complex global state. In our app, we use it to store the authenticated user's profile and private conversations+messages. If we did this in a Svelte Store where it's treated as an in-memory singleton, there's the significant potential to leak personal/sensitive data to others using the app. Furthermore, SvelteKit documentation does a good job of making the case that Stores are where complex state should happen, but makes no mention of the implicit risks and impedance mismatch when SSR is used in conjunction with Stores.

What is the recommended approach for handling complex, user-specific (private) global reactive state in SvelteKit? Are there any plans to address the implications of SSR Stores more explicitly in the documentation?

Reproduction

See #2213 for reproduction

Logs

No response

System Info

`@sveltejs/kit 1.0.0-next.282`

Severity

serious, but I can work around it

Additional Information

No response

[sjmueller]

@babichjacob it's inconsiderate to close and lock an issue without any explanation

we're trying to contribute+become part of the svelte community -- so getting auto-silenced feels like an invalidating and unwelcoming start

[dummdidumm]

You are right that an explanation is missing, and I'm sorry about that. I guess it was moved to a discussion because this is a usage question ticket, not a bug/feature request ticket. The loading docs also make it clear (IMO) that you should not use global variables (so, also stores if they are global), so it's not a documentation issue either (maybe in this discussion it turns out it is, we can always revisit this), so this was moved to a discussion.

[babichjacob]

The issue wasn't closed, it was converted to a discussion.

Further, it is a duplicate of an existing closed issue (which was also closed for being a usage question #2213 (comment)) and is a usage question rather than a bug report.

What is the recommended approach for handling complex, user-specific (private) global reactive state in SvelteKit?

The only reason I converted it to a discussion without an explicit explanation is because there is one provided by GitHub as shown, and I was confident that for the aforementioned reasons it was the right thing to do to help other maintainers with the issue tracker and because talking about the problem wasn't inhibited by doing this.

[sjmueller]

the issue was literally closed and locked, a subject we spent time discussing, researching and socializing before deciding to open -- if not a bug, it is a serious artifact in SK SSR that could yield detrimental outcomes -- still not sure why the consensus is that it doesn't deserve to be an issue, but we'll see how opinions develop in this discussion

that being said, i do appreciate you providing context around your process and reasoning, it's helpful

[AlbertMarashi]

I've proposed a solution to this problem here #9878

[dummdidumm]

You could wrap store usage using Svelte's context API. That way they are scoped to a component and its children, therefore scoped per user:

// store.js
import { setContext, getContext } from 'svelte';

export function createMyCustomStore() {
  setContext('someUniqueName', writable('some content'));
}

export function getMyCustomStore() {
  getContext('someUniqueName');
}

// src/routes/__layout.svelte
<script>
  ...
  createMyCustomStore();
</script>

// src/routes/somewhereelse.svelte
<script>
  const store = getMyCustomStore();
  ...
</script>

Note that this means that you need to call these get/set methods on component initialization.

[sjmueller]

after trying many things with @tedmeftah, we landed on stuffing in the context just like your suggestion

fingers crossed in the future we get a more semantically consistent manner of populating stores on SSR that doesn't sneakily behave differently compared to client side (i.e. avoid global shared state)

[rohanrajpal]

Hey, @dummdidumm is this still the recommended or would you recommend something better now? (with all the recent changes implmented in svelte kit)

[joaquimnetocel]

I believe that a return is missing in your "getMyCustomStore".

Here is what worked for me:

// store.ts
import { getContext, setContext } from 'svelte';
import { writable, type Writable } from 'svelte/store';

export function createStore() {
	const mystore = writable('INITIAL VALUE');
	setContext('contextStore', mystore);
}

export function readStore() {
	return getContext<Writable<string>>('contextStore');
}

<!-- +layout.svelte -->
<script lang="ts">
	import { createStore } from './store';
	createStore();
</script>

<slot />

<!-- IN ANY COMPONENT: -->
<script lang="ts">
	import { readStore } from './store';
	const storeData = readStore();
	$storeData = 'NOW YOU CAN CHANGE THE STORE WITHOUT SHARING THE VALUE WITH OTHER USERS.';
</script>

{$storeData}

[jerriclynsjohn]

This should be in the docs!

[sjmueller]

Thanks for taking the time and chiming in @dummdidumm

The loading docs also make it clear (IMO) that you should not use global variables (so, also stores if they are global), so it's not a documentation issue either

We believe the docs are neither clear nor explicit, for these reasons:

• The loading docs warning: Mutating any shared state on the server will affect all clients, not just the current one. is ambiguous about stores -- there isn't a direct correlation that stores are shared global state
• Unless I've missed it, the store docs don't mention anywhere how stores become global server-side singletons in an SSR context. This is important because anyone coming from redux (or any other SPA store concept) will see svelte stores as nearly identical in semantics, except for this huge and dangerous difference

At this point, we still feel that svelte stores should house our global state (just like a redux store), and to achieve the desired result on SSR we're using stuff to transport data from load within the module context so that we can safely initialize the store with the user's personal data. Honestly feels a bit hacky, and we still have great concern that a dev will accidentally init the store with private data directly within load, which potentially triggers a data leak:

// src/routes/__layout.svelte
<script context="module">
  export async function load({ fetch }) {
    const res = await fetch("api.blink.xyz/conversations")
    const conversations = await res.json()
    return {
      stuff: { conversations }
    }
  }
</script>

<script>
  import conversationStore from "$lib/stores/conversations"
  import { page } from "$app/stores"
  conversationStore.update($page.stuff.data)
</script>

// src/routes/somewhereelse.svelte
<script>
  import conversationStore from "$lib/stores/conversations"
</script>

<ul>
  {#each $conversationStore[1].messages as message}
    <li>{message.sender}: {message.content}</li>
  {/each}
</ul>

[sjmueller]

What do you think about the way we are populating our store with personal data using stuff as a transport? Is there a better way?

Also, would it make sense for SK to introduce a different context in which load could be used? Example:

<script context="request"> // instead of [global] "module"?
  export async function load({ fetch }) { ... }
</script>

[benmccann]

Your load function is fine (assuming there's no bug on the SvelteKit side 😄) and the suggestion you make would not help at all. The issue would be in import conversationStore from "$lib/stores/conversations". That looks likely to be a global variable. To address it, you could do as @dummdidumm suggested above: #4339 (comment)

[itssumitrai]

Hi @benmccann ,
Thanks for your reply. Could you provide me a suggestion regarding my query as well ?
I like to keep my data fetching separate from my page Component.

// index.svelte
<script context="module">
import fetchData from '$lib/actions/fetchData.js';
 export async function load(context) {
     await fetchData(context, { foo: 'bar' });
 }
</script>

The reason for doing this is:

1. Cleaner code especially when you have tons of async actions running
2. We can reuse the same action across multiple pages

Now if we want to do the above suggested stores into context. How do we access that store inside the action file ?

I get this error: Error: Function called outside component initialization when I try to use
getContext('__stores__') inside fetchData.js.
Its fine in any component though. Any suggestions on how to handle this ?
Thanks.

[pevey]

<script context="module"> export async function load({ fetch }) { const res = await fetch("api.blink.xyz/conversations") const conversations = await res.json() return { stuff: { conversations } } } </script>

It's been a couple of weeks now, but I just want to point out that the above code will not necessarily always run on the server, which seems like your intent. Here is the relevant snippet from the docs:

load is similar to getStaticProps or getServerSideProps in Next.js, except that load runs on both the server and the client. In the example above, if a user clicks on a link to this page the data will be fetched from cms.

Perhaps I misunderstand, and running server or client side, depending on the situation, would be fine for your use case. But it not, I think the better solution would be to use the context example provided by @dummdidumm.

[sjmueller]

we definitely want load to run on the server or client, depending on the circumstance

i think it all comes down to having a store-per-request, even on SSR -- and right now it seems like stuffing them into the context (like @dummdidumm suggests above) is the only way, even though it seems like a hack

[itssumitrai]

I was just about to create a post for this same issue. Since Svelte stores are generally written as files where you have to initialize it like writable(), it becomes global for all the server requests.
The only way to do this safely on server seems to be what @dummdidumm suggested above by putting the store into the context, and thats exactly what SvelteKit also does for page & other stores.
But we don't have the access to the root component, so we can't set a store into the context which would be available everywhere through the app :(
It would be great if Sveltekit could provide a way to add stores to the __svelte__ context where other stores live, that way the stores could be used easily and safely even in SSR

[hyunbinseo]

Since Svelte stores are generally written as files where you have to initialize it like writable(), it becomes global for all the server requests.

An example would be the official Stores / Writable stores • Svelte Tutorial.

// stores.js

import { writable } from 'svelte/store';

export const count = writable(0);

<!-- Incrementer.svelte -->

<script>
  import { count } from './stores.js';

  function increment() {
    // Problematic in SSR environments
    count.update((n) => n + 1);
  }
</script>

<button on:click={increment}> + </button>

[lukaszpolowczyk]

For security and clarity, all tutorials and examples (including those for pure SvelteJS, without SvelteKit) should be updated to be ready for use with SvelteKit with SSR as well.
What do you think?

[itssumitrai]

Since there hasn't been any new activity on this thread, I have been experimenting on this a little bit, and I have found that using stuff works pretty well for me. stuff is available in any load function & its specific to a given request, plus it could also be accessed using $page.stuff in any component.

So, my solution is basically not have global stores. My Store file looks like:

fooStore.js

import { writable } from 'svelte/store';
export default function () {
   return writable(0);
}

Notice that we return a function which instantiates the store. This is important to ensure we are not using global stores around on server.

Now in __layout.svelte

import fooStore from '$stores/fooStore.js';
export async function load() {
     const storeInstances = {
         foo: fooStore() 
     };
     return {
         stuff: {
            ...storeInstances
         }
     }
}

Now you can use your fooStore instance without any worry from the stuff
either as stuff.foo in load function or $page.stuff.$foo in your components.

One caveat: Sveltekit removes stuff even on the client side navigations which I find very weird to do, so that means if you want to persist stores between client side navigations, you would have to add the additional logic yourself, same would be true with getContext as well.

[itssumitrai]

@sjmueller See if that works for you

[sjmueller]

Sveltekit removes stuff even on the client side navigations ... same would be true with getContext as well

Thanks for chiming in @itssumitrai, we didn't actually realize how svelte handles stuff and context when it comes to client side navigation.

Ideally we'd have non-global stores on SSR that get populated for the duration of the request, and then those same stores stick around on the client and persist through all client side navigation. Would be great if the core team could share their thoughts and recommended approach on this issue cc @Rich-Harris

[AlbertMarashi]

Ok but it's just a bit annoying having to do this everywhere across my code $page.stuff.alerts...

[itssumitrai]

I agree, I just created a util method for this getStore(storeName). I haven't really found any good alternative solutions for this problem.

[AlbertMarashi]

I kinda agree with this, there should be a JS sandbox being created per request. I understand the overhead, but i think it's critical for security, many devs are probably unaware of this caveat, despite a small note about it in the docs

[Kraftwurm]

many devs are probably unaware of this caveat

You are so right. I'm very glad to have stumbled upon this conversation!

[AlbertMarashi]

@dummdidumm @Rich-Harris I have experience playing around with Vue's sandboxing system that they use to isolate module state from eachother using node's vm features. I would be happy to collaborate with someone, with the goal of creating a sveltekit adapter to achieve this.

Using stores like normal javascript I find is generally the most convenient and not needing to worry about potential security vunerabilities between shared user state is a big plus.

[AlbertMarashi]

I have opened an issue to request a sandboxed-version of the sveltekit adapter. Please see here #5231

[AlbertMarashi]

It appears Vite is capable of supporting this without using node's VM features. See here
#9878

[sjmueller]

thanks for pushing this forward @AlbertMarashi

[AlbertMarashi]

Thanks @sjmueller I don't like the fact that a serious concern was closed like that, and I think there should definitely be an option for sandboxing of SSR state, or at least a better way to manage stores across svelte

[AlbertMarashi]

@sjmueller let me know what you think of #9878
It proposes a quite nice solution I think of how to make file-based stores safe and usable

[giray123]

Eventually we have also come accross this problem. This seems like one of hte biggest issues of Sveltekit. All solutions proposed seems not cool considering the ease-of-use of Sveltekit. What is the disadvantage of restricting the stores on the request context?

Additionally, currently tried the below approach (upon populating store on SSR). We get an empty store on SSR. But this also does not help because since it gives an empty store on each server import, it is meaningless.

export const hello = writable<string | null>(null)

export function getHelloStore() {
	if (!browser) {
		return writable<string | null>(null)
	} else {
		return hello
	}
}

In the end I am really really confused, as far as I understand either you set a store on script or a script context it changes the shared store on server. This is a very dangerous thing and all the examples in the docs are susceptible to this. Please correct me if I am wrong. The docs are directly directing to a security vulnerability. (yes, there is a sentence about this but I am referencing almost all the store code examples.)

@Rich-Harris, what is really interesting is that there have been 2 issues about this problem, 1 is closed and the other (this one) is converted into a discussion. For me and my team this is the number 1 issue currently in Sveltekit. Can somebody from Sveltekit please explain what is the ultimate correct way to use the stores considering the SSR and security?

[CaptainCodeman]

I'm not 100% sure, but I think this is the same issue that I came across (or at least very similar) where I wanted to have a store, using server-rendered data, but then upgrade that store to become client-side once hydrated - in my case because I'm them subscribing to Firestore on the client (but want the initial fast load). In addition, I don't want to load data from the server on each navigation once the client is hydrated.

I figured out a way to do it but it's not obvious. Hopefully this is enough of a gist to explain the approach ...

First, maintain a flag to know if hydration has happened:

import { browser } from '$app/env'

// In order to prevent the browser doing both a fetch of data from and endpoint
// and a subscription to Firestore, we keep a flag to indicate if we're doing
// the initial load on the client or not (based on whether hydration has run).
// Note that even though we do the fetch on the client for the first execution
// we don't actually go across the network because of how SvelteKit embeds the
// JSON payload into the page, so it acts as a way of getting that initial SSR
// content to seed the store with, while the Firestore subscription is loading.

let _hydrated = false

if (browser) {
  window.addEventListener('sveltekit:start', () => _hydrated = true, { once: true })
}

// returns true if the code is running in the browser and hydration has completed
export const hasHydrated = () => _hydrated

Have two store implementations, one very simple to just contain the data:

export const contentsFactory = (contents: any[]) => writable(contents)

And one richer to do the client-side pieces (in this case, the firestore subscription):

export function clientContentsFactory(site, contents) {
  const { subscribe } = writable(contents, set => {
    const q = query(collection(firestore, 'blog', site, 'content'), limit(5))
    const unsub = onSnapshot(q, r => {
      const contents = r.docs.map(doc => toJS(doc))
      set(contents)
    })
    return unsub
  })

  return { subscribe }
}

The load function uses the hydration flag to determine which store to use and also to do the server-side fetch if required. The loaded data is used to seed the store on both server and client, which prevents any flash of SSR'd data before the client-subscribed data then replaces it.

<script lang="ts" context="module">
  import type { Load } from '@sveltejs/kit'
  import { contentsFactory } from '$lib/stores';
  import { browser } from '$app/env';
  import { clientContentsFactory } from '$lib/firebase-client';
  import type { Readable } from 'svelte/store';
  import { hasHydrated } from '$lib/hydrated';

  export const load: Load = async ({ fetch, params }) => {
    async function fetchData() {
      const resp = await fetch('/api/contents?blog=' + params.site)
      const data = await resp.json()
      return data
    }

    const data = hasHydrated() 
      ? []
      : await fetchData()

    const contents = browser
      ? clientContentsFactory(params.site, data)
      : contentsFactory(data)

    return {
      props: { contents },
    }
  }
</script>

<script lang="ts">
  export let contents: Readable<any[]>
</script>

<h5>Contents</h5>

<ul>
{#each $contents as content}
  <li>{content.id}</li>
{/each}
</ul>

As I said, it's non-obvious and it's easier to understand if you step through it in the debugger. There are really 3 paths through the load function: SSR, SSR being re-hydrated on client, client-side navigation.

Apologies if it's not really relevant, but even so it may give you some ideas.

[giray123]

I kind of understand what you did there. Thanks for sharing. Again, this feels like a lot of hacky code to make a simple thing to work. And if you set a store variable in your script anywhere as in the examples, again it will be a problem on SRR. The main advantage of stores in the end is that we import them inside multiple components to do some stuff in the script tag. The only correct way, as I see, is to make the stores request-specific at the server. I feel that it should not be a huge thing to implement but probably I am missing something that the devs would explain.

[raduab]

We ran into the same issue with our app. Data was leaking between requests, and we also used server-side authentication, so this posed a significant security risk. I ended up writing a custom store that could be used in the same way as Svelte's default writable store, using the context as previously suggested. This custom store is sandboxed on the server, and it becomes a Svelte writable store on the client:

// sandboxedStore.js
//

import { browser } from '$app/environment'
import { getStores } from '$app/stores'
import { v4 as uuidv4 } from 'uuid'
import { get, writable as svelteWritable } from 'svelte/store'

const storesKey = `sandbox_${uuidv4()}`

/**
 * Creates a façade for a writable store that is a sandboxed store that may be used as a
 * global variable. It must be initialized during component initialization.
 *
 * This store is contextual since it is added to the context of the root component. This means that
 * it is unique to each request on the server rather than shared across multiple requests handled
 * by the same server at the same time, allowing it to be used as a global variable while also
 * holding user-specific data.
 *
 * We must subscribe to this store during component initialization before we can use it. It is
 * utilized in the same way as [SvletKit's app stores](https://kit.svelte.dev/docs/modules#$app-stores).
 *
 * _NB: In async methods, set the store before any await, otherwise, the context will be lost once
 * the promise is fulfilled._
 *
 * @param {any} initialValue An initial value to set the store to
 * @param {string} [key] An optional key name for the store
 */
export function writable(initialValue, key) {
  key = key ? `${key}_${uuidv4()}` : uuidv4()

  function setStore(value) {
    try {
      const { page: sessionStore } = getStores()
      const session = get(sessionStore)

      const store = session?.[storesKey]?.[key]
      const currentValue = store ? store.value : initialValue

      if (!store || value !== currentValue) {
        if (!session[storesKey]) session[storesKey] = {}
        session[storesKey][key] = {
          value,
          subscribers: store?.subscribers || [],
        }

        // alert subscribers
        if (store) {
          store.subscribers.forEach(fn => {
            fn(value)
          })

          // return the updated value
          return value
        }
      }
    } catch (error) {
      // if we reached this exception, it meant that the store had not yet been initialized
      return value
    }
  }

  const sandboxedWritable = {
    set: setStore,

    subscribe: fn => {
      try {
        const { page: sessionStore } = getStores()
        const session = get(sessionStore)

        const store = session?.[storesKey]?.[key]
        const currentValue = store ? store.value : initialValue

        // call the subscription function with the current value
        fn(currentValue)

        // register the subscriber
        if (!session[storesKey]) session[storesKey] = {}
        session[storesKey][key] = {
          value: store?.value || initialValue,
          subscribers: [...(store?.subscribers || []), fn],
        }
      } catch (error) {
        // if we reached this exception, it meant that the store had not yet been initialized
        // call the subscription function with the initial value
        fn(initialValue)
      }

      // return the unsubscribe function
      return function unsubscribe() {
        try {
          const { page: sessionStore } = getStores()
          const session = get(sessionStore)

          // unregister the subscriber
          const { subscribers } = session[storesKey][key]
          subscribers.splice(subscribers.indexOf(fn), 1)
        } catch (error) {
          // if we reached this exception, it meant that the store had not yet been initialized
          // ignore
        }
      }
    },

    update: fn => {
      try {
        const { page: sessionStore } = getStores()
        const session = get(sessionStore)

        const store = session?.[storesKey]?.[key]
        const currentValue = store ? store?.value : initialValue

        setStore(fn(currentValue))
      } catch (error) {
        // if we reached this exception, it meant that the store had not yet been initialized
        setStore(fn(initialValue))
      }
    },
  }

  return browser ? svelteWritable(initialValue) : sandboxedWritable
}

EDIT: I updated the code, to remove stuff that was no longer available in the page store, e.g.:

  const { page: sessionStore } = getStores()
- const { stuff: session } = get(sessionStore)
+ const session = get(sessionStore)

You can use this writable store in the same way as the default one, with the exception that it will not leak data on the server between requests. You can also specify a value to initialize the store with, which will be set only after the context is available:

import { writable } from 'sandboxedStore'

const foo = writable()
const bar = writable('initial value')

[Bewinxed]

I don't know why a lot of people are surprised about user-specific stores, I think the majority of usecases would like stores to be user specific and not global.

why can't we just writable(value:any, global:boolean)?

This solution helped a lot!

[raythurnevoid]

How is this better than using context? #4339 (comment)

[wiwa]

I was able to get this to work in Typescript by using const session = get(sessionStore).data (added the .data). Honestly, not sure how we can just mutate the App.PageData like that.
For now, I'm using get(sessionStore).data.stores, and then in my routes/+layout.ts:

import type { LayoutLoad } from "./$types";

export const load = (async () => {
  return {
    stores: {}
  };
}) satisfies LayoutLoad;

I'm also not sure why we need the const storesKey = sandbox_${uuidv4()}` -- I'm assuming this is so the key doesn't conflict with any key we might use in our application.

[wiwa]

@raythurnevoid this is better than using context api because:

1. It is a drop-in replacement for Svelte stores instead of requiring significant boilerplate code.
   a. Don't need to cast to get the right types.
2. You don't need to be careful about referencing the store during component initialization.

[sulitprod]

Who tried to call the store inside +layout.svelte, but set the value in +page.svelte?
I have this structure:

(profile)
- profile
-- +page.svelte
- [@id]
-- +page.svelte
- +layout.svelte

The page of your profile and someone else's are identical except for a couple of UI elements and additional pages, which means that you need to pass basic information to the layout, but I encountered the fact that the store is empty on the first render, so the profile flickers on the first load.

[aradalvand]

I absolutely agree that this behavior is non-obvious and as such should be mentioned and explained much more clearly in the docs.

Declaring a store in a separate file and then importing it in components and so on is how you do global stores in vanilla Svelte, and so many people are probably assuming they can do the same thing in SvelteKit, while not actually realizing that it could be problematic.

[alucav]

i am thankful that i stumbled across this post. these issues were feeling insurmountable. @raduab thank you so much for taking the time to share what your elegant solution. with the recent updates, it seems to not be fully working. i have to make it work on a project so if I am able to I will post the modified version here.

glad to be part of such a great community.

update: this is actually working just fine with the current version ("@sveltejs/kit": "^1.0.0-next.443"). The issue was in my implementation.

[kvetoslavnovak]

I would really prefer in build solution for the store in SSR with sensitive user data. Maybe leaving session store behind (removal of the session store) was too hasty.

For the use cases discussed here the old session was really great and easy to use tool/. Even tools like Supabase SvelteKit Auth Helpers were build upon and embraced this feature.

[aradalvand]

Yes, the removal of the session was an absolutely horrid decision and I'll die on this hill.

[nickyhajal]

I have been hitting this issue as I mentioned here #8614 (comment).

Is @raduab's solution above still what most people here are using? Has any progress been made else where that I'm missing?

Thanks!

[raduab]

This is still used in production after being updated to reflect the most current SvelteKit changes (see above)

[wiwa]

Hi! Thanks for bringing up this info. Imo, this is quite unexpected behavior, and if a developer of an API needs people to read very carefully, then their users are not going to read (hi, user here).

(All in my newbie opinion:)

In Svelte (i.e. just client-side), stores don't have cross-session behavior (i.e. User1 will never see User2's info).
It doesn't make much sense that SvelteKit would add this behavior, and only when using SSR (not even purposefully changing the store on the server). An app rendered client-side which can be rendered server-side should not change its behavior just because SSR was turned on. (As a newb to frontend) I expect SSR to "simply" be a performance enhancement, assuming the semantics of my web app allow it to be switched on. In this paradigm, SSR should not change the sandboxed nature of client-only stores.

Otherwise, I would personally just turn off SSR if I'm using stores, unless I were using a workaround like those in this discussion.

[cedricr]

Otherwise, I would personally just turn off SSR if I'm using stores

Unfortunately, turning off SSR with SvelteKit, and contrarily to what the documentation says, you're loosing all SEO, not some of it. From the experiments I've done, Google was unable/unwilling to fetch more than a few of the dozens of javascript files necessary to render a page, and I wasn't able to find how to have SK generate a unique js bundle either…

[oneserv-heuser]

We were having the exact same issues and started to use prerender.io, but that brings in lots of more problems and is just a workaround as Google says itself (https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering).

So we rebuild our application with SSR and now facing the problems described in this thread with shared global stores on the server side which is a huge bummer.

[nickyhajal]

Here's how I have been dealing with this...

In layout.server.ts I have something like this:

export const load = (async (req) => {
  ...
  return {
    community,
    me,
  }
}) satisfies LayoutServerLoad

In layout.svelte I have:

<script lang="ts">
  const me = writable<MeType>($page.data.me)
  const community = writable<CommunityType>($page.data.community)
  setContext('me', me)
  setContext('community', community)
</script>

Then, I have $lib/getContexts.ts:

export function getCommunityContext() {
  return getContext<Writable<CommunityType>>('community')
}
export function getMeContext() {
  return getContext<Writable<MeType>>('me')
}
export function getFullContext() {
  return {
    community: getCommunityContext(),
    me: getMeContext(),
  }
}

That way, throughout my app I can just start typing getComm... and the auto-import correctly finds my context function.

From any component, I can simply add:

const community = getCommunityContext()

And I quickly have access to the store I want.

For me, this feels like a nice pattern that matches the ease-of-use from how I used stores before SvelteKit (easy auto-import, minimal boiler plate), but makes more sense with SK's natural data flow.

Hope that may help someone else, let me know if I'm missing some flaw in my own setup!

[aradalvand]

$: community = getCommunityContext() should just be const community = getCommunityContext().

[PlopTheReal]

I guess this also work from a library right?

[nickyhajal]

$: community = getCommunityContext() should just be const community = getCommunityContext().

Yes, thanks! Updated in my post above

[devunt]

I made the simple utility to keep server states isolated per request.
Since page object's reference changes on every request, we can safely use them as key for WeakMap.
As soon as page object is refreshed, it will be garbage-collected automatically and no memory leaks will happen.

// src/lib/store.ts

import { get, writable as writable_ } from 'svelte/store';
import { browser } from '$app/environment';
import { page } from '$app/stores';
import type { Writable } from 'svelte/store';

const stores = new WeakMap();

export const writable = <T>(value?: T): Writable<T> => {
  if (browser) {
    return writable_(value);
  }

  const key = get(page);
  let store = stores.get(key);

  if (!store) {
    store = writable_(value);
    stores.set(key, store);
  }

  return store;
};

You can now use them safely as a global variables.

// src/lib/stores.ts

import { writable } from '$lib/store';
export const counter = writable(0);

<!-- src/routes/+page.svelte -->

<script lang="ts">
  import { counter } from '$lib/stores';
  store.update((v) => v + 1);
  console.log($store); // This will always print `1` on both the server and the browser.
</script>

Since this is just a small snippet, there's no magic here. You can modify it for your needs.
As this is not extensively tested, please use with caution. But I'm pretty sure this will work in most cases (though not tested).

[SQLSourcerer]

If I'm reading this right, this will only allow one store per session

[forna]

It produces this error whenever the page is refreshed:

Internal server error: Cannot subscribe to 'page' store on the server outside of a Svelte component, as it is bound to the current request via component context. 
This prevents state from leaking between users.For more information, see https://kit.svelte.dev/docs/state-management#avoid-shared-state-on-the-server
      at get_store (/node_modules/@sveltejs/kit/src/runtime/app/stores.js:77:9)
      at Object.subscribe (/node_modules/@sveltejs/kit/src/runtime/app/stores.js:32:24) 
      at subscribe (/node_modules/svelte/internal/index.mjs:59:25)
      at Module.get_store_value (/node_modules/svelte/internal/index.mjs:64:5)
      at Module.writable (/src/lib/store/store.js:16:39)
      at eval (/src/lib/store/stores.js:5:42)

[bcla22]

Is there a reason this thread is over a year old and the team still has not addressed it? My team and I are evaluating Sveltekit as an alternative to Nextjs but leaking data between sessions on SSR is immensely dangerous and given all the other conveniences of Sveltekit, surprising that such a pitfall exists. We've had success using @raduab's example above, but it still feels hacky that its not an official part of the framework, especially something so fundamental to many use cases.

[wiwa]

You're assuming people who want to intentionally do so are the only ones who will run into this issue.
Furthermore, if it's true that you should never use a store on the server, just disable that ability in the framework. Sounds like a "holding the phone wrong" moment to me.

[sjmueller]

like almost everything with ssr, the goal is to create a snapshot of html+state that can then be rendered on the client as fast as possible and be ready for interactivity+reactivity as early as possible

therefore the whole point of “hydration” is to continue on the client with the same constructs and paradigms that you started with on the server

svelte kit is currently breaking the trust of this well-established paradigm, full stop

[nickyhajal]

It's not that I'm "intentionally using a store on the server", when I encounter this.

I use a store in pages and components. I want that data to render server-side and then be reactive on the client. That means the store is accessed on the server and on the client.

It doesn't seem to make sense to me to have a different method for managing state when rendering on the server vs. the client so I don't understand why some have acted like it is an odd request to expect stores should work while server side rendering.

The solution I posted above using context has been working for me, but I do think that if you're coming from Svelte to Sveltekit, it is very confusing why stores don't work as expected.

[CaptainCodeman]

I think any use of Context may just happen fix things because there is some other change to where a store is created as part of it. Context is really for having separate trees of components with their own scope (which can include stores). So I'd focus on the "where is the store created / what is it's scope" side of things.

In SvelteKit there is already the page store that can provide scope on the client. Creating and returning a store in a load function makes it available.

The key part is creating though ... if a store is created in a separate file and imported, then it has a different scope. In that case the trick is to export a factory function to create a store, not export the store itself.

That would be a good "danger Will Robinson" example of what should / shouldn't be done.

[wiwa]

The "sandboxedStore" workaround in this discussion uses the page store to deal with possible ssr issues.

However, it's clunky, and honestly ridiculous that we need such a workaround using what feels like a hack.

For newbs to SvelteKit, we don't want to be experts, we want to make an app.

It's fine if SvelteKit prefers a certain philosophy over UX, but perhaps that should be made clear -- that developer experience is secondary.

[colourcountry]

Just came across this and was as surprised as anyone else.
I think I was misled by the docs for $app/stores which says "Stores on the server are contextual — they are added to the context of your root component."

Reading it back I realise the section was specific to those 4 built-in stores, but it sounded like a general principle. It should probably say "These stores on the server..." and also carry a warning that stores you create won't behave like this unless you do the adding to the context yourself.

[lxhom]

Regardless of whether per-request stores will get implemented or not, there should at least be a warning for the time being. If you import the page store in a module context, it gives you this warning:

Internal server error: Cannot subscribe to 'page' store on the server outside of a Svelte component, as it is bound to the current request via component context. This prevents state from leaking between users. For more information, see https://kit.svelte.dev/docs/state-management#avoid-shared-state-on-the-server

The same warning should apply to any other writable store that's not in a context too. This is a huge pitfall.

[devunt]

I just published a drop-in replacement package for svelte stores that is safe to use with sveltekit ssr.
If anyone looking for simple solution, it might help.

https://github.com/devunt/svelte-stores

[lxhom]

When would the values in these stores be unset? As the application runs, would the stores grow in memory usage with each new visitor?

Not OP, but I'm building a similar library and know what @devunt is doing. It is using a WeakMap. It stores objects but doesn't prevent them from being garbage collected, so the lifetime is exactly as you would expect it. You can look on MDN for more infos.

Also note that this has a caveat: The stores only start existing in a page context, so you cannot .set() them in a module context, but it should be fairly easy to work around that by extracting the code using .set onto a function and calling that in the top level layout

[Maxiviper117]

So this is for when we create writable stores on the server and not relevant to for stores created on the client side pages or components?

[nickyhajal]

@Maxiviper117 Yes, but if you are server-side rendering, your "client" is running on the server for the initial page load. So you have to beware of that.

[Maxiviper117]

@nickyhajal but the data in the store is isolated if we use the context api workaround or devunt solution?

[nickyhajal]

Correct 👍

[Gilgames000]

Looks like I unintentionally avoided this SvelteKit security vulnerability by running my webapp on Vercel 😁🤝

[grantjayy]

How does running your app on Vercel prevent this ? Serverless environments can handle multiple requests before the instance dies, so your state can still leak.

[jdgamble555]

I wrote an article where I built simple universal contexts like so:

use-shared-store.ts

import { getContext, hasContext, setContext } from "svelte";
import { readable, writable } from "svelte/store";

// context for any type of store
export const useSharedStore = <T, A>(
    name: string,
    fn: (value?: A) => T,
    defaultValue?: A,
) => {
    if (hasContext(name)) {
        return getContext<T>(name);
    }
    const _value = fn(defaultValue);
    setContext(name, _value);
    return _value;
};

// writable store context
export const useWritable = <T>(name: string, value: T) =>
    useSharedStore(name, writable, value);

// readable store context
export const useReadable = <T>(name: string, value: T) =>
    useSharedStore(name, readable, value);

https://dev.to/jdgamble555/the-correct-way-to-use-stores-in-sveltekit-3h6i

Although, this should be built into SvelteKit to prevent bad SvelteKit coding!

J

[brendanmatkin]

@jdgamble555 nice idea! You beat be to the article punch. I wrote something that clarifies what is happening, why it is bad, what the documentation lacks, and how to implement basic contexts (as shown in the docs).

https://dev.to/brendanmatkin/safe-sveltekit-stores-for-ssr-5a0h

[AlbertMarashi]

I have created a proposal to solve this issue and allow safe, ergonomic and usable file-based stores for svelte:
See more
#9878

[jdgamble555]

Very interesting and unique!

SvelteKit team (@dummdidumm, @sjmueller), this should be built into SvelteKit so users don't have to think about this problem. There will inevitably be many bad coders that don't understand nor consider this as a problem!

J

[AlbertMarashi]

@jdgamble555 could you comment & provide your feedback into the proposal discussion

[jdgamble555]

I'm not familiar enough with Vite, but if it solves the problem internally without the dev having to think about it, I'm all for it

[Maxiviper117]

[jdgamble555]

You can import a store from anywhere, same problem.

J

[jdgamble555]

@Maxiviper117 - Stores on the client and stores on the server are not related and cannot share data. This discussion is referring to the problem with stores (declared as globals outside of components) ability to be leaked to another user since the data would persist. If you have issues understanding why please ask else where, as this post is for solving the problem at hand.

J

[samal-rasmussen]

This breaks the Principle of Least Astonishment so much: https://en.wikipedia.org/wiki/Principle_of_least_astonishment

I am truly deeply astonished.

[winfredjames]

Their response for this issue is truly disappointing.

[AlbertMarashi]

@winfredjames Please provide feedback on solving this issue with my proposal here #9878

[aloker]

To be honest, I don't think this requires a technical solution. Sticking to good programming practices is sufficient. Devs should just avoid using globals. Really, this has been taught for decades, long before web dev was a thing.

If you need per-request stores, put them in context and/or locals and pass them explicitly to the functions that require them. A pure function that does not reply on implicit global state is much less trouble.

I know putting stores in global variables has been common practice for many Svelte devs pre SevelteKit. In SPA scenarios people got away with it, but now these practices backfire. That's not an inherit issue with Svelte, just bad practice.

So, IMO, this problem is not a technical one. What's needed is better training (don't use globals unless it's for true singletons; write functions as pure as possible). The docs could be more explicit about this, I guess, but it's clearly mentioned.

I don't want to sound condescending. I just don't believe this is a bug that needs fixing.

[samal-rasmussen]

This is such a biggie it should be demonstrated in the tutorial and not just left as a detail you can easily gloss over in the docs.

[sjmueller]

"I don't want to sound condescending" usually precedes sounding condescending.

The problem isn't training, the problem isn't singletons. The problem is that stores are working one way in an SPA but then behaving dangerously on the server side. It's horribly unintuitive. Nobody would use a store globally for all users within an SPA, and literally nobody wants it to function this way on the server.

Make stores work the way people would expect them to work on the server. Anything else is a violation of expectations, a disappointment, and a failure of sveltekit.

[aloker]

When you say "Make stores work the way people would expect them to work on the server", do you literally mean stores only, or global variables in general? If the former, why only stores? If the latter - how would I go and create a "true" global variable? And how would such transparent request isolation work technically across all target environments?

As it is now, it's very consistent: a global variable is shared by every accessor. On the server this means every request, on the client, this obviously only means the one browser tab the app is running in. It's simple, no magic involved. Adding more magic to the system would not make it easier.

There are other places where you have to be aware of the difference of server side and client side (onMount, accessing the window object, etc). Why should global stores be different? It's a misconception that isomorphic apps remove server vs client from the equation.

I repeat myself, this is a question of training and documentation. And I do agree that there should be a clear explanation of all this as one of the first pages in the docs (maybe there is, I haven't checked recently).

[AlbertMarashi]

If you guys want to see this issue solved, please provided feedback on my proposal here #9878

[silverdilver]

I'm trying to wrap my head around all of this so hopefully someone can confirm if my understanding is correct.

I get if I make a store inside +page.server.ts outside of the load function, that object is effectively created once and then any changes to that are therefore shared between all requests which opens it up to leaking data.

What I'm struggling to wrap my head around is if a store is created using a store.ts file, and that is created/used within a +page.svelte, can data leak on the server that way?

Eg Skeleton has a warning around this for some of their utilities, as behind the scenes they use stores which work via exporting the store as a const

Is this only a danger if it's used within a load function (both +page.server.ts & +page.ts), or is it also a risk to use that within +page.svelte?

[nickyhajal]

It is a risk because when +page.svelte is generated by the server for SSR, then it will again be using shared state between requests.

Using a context for the store on the layout or page forces the it to be recreated on each request, even on the server.

[Maxiviper117]

I had a somewhat similar head scratch but came to an understanding here: https://discord.com/channels/457912077277855764/1107384981921210418

[joaquimnetocel]

Could someone tell me if svelte 5 runes address this problem somehow?

[jdgamble555]

Nope, not out of the box - https://dev.to/jdgamble555/create-the-perfect-sharable-rune-in-svelte-ij8