How to read/write a store from client and server, now that Load.session has been removed.

[dannyvelas]

I develop an external backend that the client-side and server-side of my SvelteKit app send requests to. These requests require a header with an accessToken value. Every now and then, this access token needs to be refreshed.

For these reasons I need to be able to read/write this access token value before sending any request, which may happen at either client or server. Below are some approaches I tried:

1. Return the access token in my root layout.server.js file

   • Reading from client/server ✅ with parent.data or $page.data.
   • Writing from client/server ⁉️
     • I couldn't find a way to update this token from anywhere. This discussion has an answer of how to update a value in the +layout.js by using depends and invalidate in client-side load functions.
     • But, how would I update this access token in client-side code outside of load functions?

2. Keep the access token in a store

   • Reading/writing from client ✅
     • *.svelte files can easily read/write the access token. I think load functions that run on the client-side will be also be able to read/write from this store.
   • Reading/writing from server ❌.
     • Server side load functions seem like they won't be able to use this store without accidentally using a global singleton.
     • So, server-side load functions will just have to fetch a new access token to use before requests. They will never be able to update tokenStore if its access token was expired.

In approach 1, on the client side, how could I update the access token for all future client/server requests?
Is approach 2 my best bet? Or, are there any alternate approaches I should consider?

Dropdown to see what the second approach would look like this in my load functions

  let accessToken = "";
  if (browser) {
     accessToken = get(tokenStore)
    /* update accessToken and tokenStore here if accesstoken expired */
  } else {
    accessToken = fetch('example.com/access-token',{...});
  }
  apiCallWith(accessToken);

Note:

• I don't want to store the access token in localStorage out of prevention for XSS. I don't want to store it in a cookie out of prevention for XSRF

[dannyvelas]

In approach 1, on the client side, how could I update the access token for all future client/server requests?

According to Rich Harris, it seems like the only way to update the client-side is also to use invalidate and cause load functions to re-run. There is no way to directly update values in $page.data.

Is approach 2 my best bet? Or, are there any alternate approaches I should consider?

I was using cookie-based authentication to fetch access tokens. And, I came to two very important realizations:

1. Cookie-based authentication between the SvelteKit server and an external server will fail
2. Consequently, The SSR benefits of SvelteKit completely disappear in this case

Explanations:

1. In cookie-based authentication, an external server will set the cookie of its client. Next time that client sends a request, the server can read the request's cookie to determine whether that request is authenticated. An external server can set a cookie in a browser to allow client-side svelte code to make authenticated requests. In contrast, this external server won't be able to set a cookie in the SvelteKit server¹. So, all server-side requests will fail with "Unauthorized" responses. You can test this out by refreshing the page of a signed-in user. This triggers a server-side execution of a load function that will fail with an unauthorized error. This response will be rendered briefly. Next, the client-side load function will promptly execute, succeed, and re-render the page with the correct info.
2. Since page-loads from the SvelteKit server will always return Unauthorized responses, the benefits of SSR disappear:
   • Users will have to wait for the client-side load functions to run anyway.
   • Users in an environment that cannot execute JS will only see pages load with Unauthorized errors.

TLDR:

Since all my requests to get a new access token from the server-side would fail with "Unauthorized," I realized that approach 1 was impossible.

As an alternative, I could refresh access tokens in +layout.ts instead, making sure to do so inside of an if(browser) block. I would be able to read/write from client. And do neither from the server.

This approach has the same benefits as my original second approach. The second approach is better as using stores feels much more natural than depends and invalidate.

Footnotes

1. I wouldn't be able to have my external backend set a cookie on the Svelte server. This is because the server, unlike a client, "serves" multiple users. So, on a client, a cookie that I set is specific to one user. On the server, this cookie would be shared among all users, which is definitely not what you want. ↩