feat!: new implementation of sessionCookieStore

[johannes-lindgren]

What

A new implementation of sessionCookieStore. It is based on the old one, with the following changes:

• The autoRefresh option in sessionCookieStore.get is removed since we've never used it. This is a breaking change, We can reintrodice it later if we need it.
• There are four crud operations for getting, setting, and removing app session cookies: get, getAll, put, and remove. The implementation of these are now moved to dedicated files; getSession, getAllSessions, putSession, removeSession.
• Created a utils module that is only used by the crud module.
• The utility function matches was renamed to keysEquals and moved to its own file.
• The utility function toKeys was renamed to keysFromQuery and moved to its own file.
• getSignedCookie and setSignedCookie were changed so that they no longer depend on Node.js (http module)

Why

In the session module, the only point where there is a dependency on Node.js is in sessionCookieStore.ts. All the other functions accepts functions for reading and writing string values (GetCookie and SetCookie), but they're actually completely agnostic to how these values are stored. This has two benefits that we will be able to leverage in the future:

• It will become easy to make the library framework agnostic.
• It will become easy to offer alterative ways of storage. It will be better if the accessToken is securely stored in a database instead of in a cookie (like we do with the deployments apps).

The next step will be to replace grant with our own, custom request handlers.

How to test

Run the Nextjs starter project locally.

yarn dev

Check out this branch and build the project.

yarn build

Link the packages with:

In the library:

yarn link

and in the template

yarn link @storyblok/app-extension-auth

In the browser, clear the cookies and reload the app. Everything should work just as before without any modification to the code.

[eunjae-lee]

Is this always called from the browser? Or is there a possibility that this can be run on the server side?

[johannes-lindgren]

Always called from the server

[eunjae-lee]

ah okay. then don't we need to pass fetch from node-fetch package?

[johannes-lindgren]

Gosh, you're right 🤯

In the very beginning, the library used to have code running in the client as well as on the server. It seems like I've forgotten to purge the tsconfig compilerOptions.lib "dom" option.

The library has only been used by us in a Next which uses the isomorphic-fetch, so we never noticed.

I've opened a new ticket for it here: https://storyblok.atlassian.net/browse/EXT-1531

[eunjae-lee]

Nice! Does the ticket include the replacement of fetch with node-fetch? Or how do you want to approach that part?

[johannes-lindgren]

I'm not sure yet... there are a few options:

• use node-fetch
• require node version >= 18 (where fetch was added)
• use openid-client to make the refresh request. When I'm replacing grant, I'll use the openid-client library for making request to the Storyblok API.

Probably the last option here

[eunjae-lee]

So far, from my understanding this sessionCookieStore is still relying on the Node.js request and response object because getNodeCookie and setNodeCookie expects them. And your plan to going to make this replaceable? Is it the changes you told me you're thinking of?

[johannes-lindgren]

Yes exactly.

It also makes the other functions easier to test, because we don't need to mock request and response objects; just the getter and setter functions.

[eunjae-lee]

This PR looks good. Let's move onto the next one! :)