Long cookies

[KnisterPeter]

Hi there,

the current SessionStorage api does not allow cookies which are too long. The default implementation throws if a cookie is more than 4096 bytes. This could be too short if there are longer data to be stored which would required multiple cookies to encode/decode all data.

I understand that this is not part of the default cookie implementation, but the current API of the session storage does only return a single string (cookie header) from the commitSession call. It does not even receive a response object to write additional headers (multiple cookies) or deal with that in any other way.

Someone elso also has this issue already? How to deal with that?
(e.g. we would like to use remix-auth with OAuth2 strategy. And the resulting token, refresh-token, id-token are too long for a cookie)

[alexanderson1993]

That specific length - 4096 bytes - is not an accident. It's actually a limitation of browsers themselves, not the Remix API.

http://browsercookielimits.iain.guru

You've got a couple of options here:

• Only store an opaque session ID in the cookie and store the token, refresh-token, id-token, etc. in a database or file
• Split the token, refresh-token, id-token, etc. across multiple cookies.
• Find some way to compress that data so it fits in 4096 bytes.

[kiliman]

Ah, yeah that was browser code.

It looks like it'll be easier to create your custom session store. You can base it on the current cookie store.

https://github.com/remix-run/remix/blob/main/packages/remix-server-runtime/sessions/cookieStorage.ts

[sergiodxa]

I would also reconsider storing the id_token, while access and refresh tokens can be short, id_tokens tend to be really large because they give you a lot of data, data that you typically can fetch again using the access token when needed. The id_token is usually intended to be used on client-side apps so you keep the user data in-memory there.

[petejodo]

unfortunately azure's access token is over 4kb on its own, I've tried to find documentation on their side because it seems to store data duplicate of the id token but to no luck

[bluefire2121]

The solution I use for Azure:
Keep the refresh token in the session cookie.
Store the access token in server cache. If you're using Node, node-cache works great.
Create a function to read the accessToken from cache so long as it hasn't expired. If it has expired, use the refreshToken to get a new accessToken, set the session, update the accessToken in cache, then commit the session.

I'll be looking into file storage as memory gets swiped on server restarts:
https://remix.run/docs/en/main/utils/sessions#creatememorysessionstorage

[manzaloros]

@bluefire2121 , thanks for the explanation — I'm going to try that. Do you have any example code of this setup / flow?

[Visible-Radio]

Someone elso also has this issue already? How to deal with that? (e.g. we would like to use remix-auth with OAuth2 strategy. And the resulting token, refresh-token, id-token are too long for a cookie)

@KnisterPeter, what did you end up doing? I'm looking at the exact same situation.

[KnisterPeter]

Hi @Visible-Radio, in the end we reduced our cookie load (the auth token does hold a lot less information). But in between I've implemented a way to split the cookie data over multiple cookies.

[Visible-Radio]

Hey! Thanks for the reply. I'm looking at opting out of using any of the sessionStorage stuff from remix and just minting the cookies myself using the actual return value from authenticator.authenticate. I'm finding the combination of remix-auth, large tokens and cookieSessionStorage very unwieldy.

[kiliman]

I always felt that cookie-based session storage was meant for simple stuff since it literally encodes all the session data in the cookie. The session API is still useful as it can be used by various Remix-compatible packages. But generally, you should use some type of server-side session store.

[KnisterPeter]

Debatable 😉
But yes there are always pros/cons and cookies which are too large are a burden for sure.

[sergiodxa]

If your session data is too large to fit in a cookie, the simplest solution is to change your session storage to don't use createCookieSessionStorage and instead use a different one that stores the session data somewhere else.

[huzaifaali14]

Here is how I handled this is issue by creating a getSessionStorage helper function.

import { config } from './config/env-config';
import type { SessionData, CookieSerializeOptions, Session, CookieParseOptions } from '@remix-run/server-runtime';

interface IGetSessionStorageResponse {
    commitSession: (data: Session<SessionData, SessionData>, options?: CookieSerializeOptionsExtended) => Promise<string>;
    destroySession: (session: Session<SessionData, SessionData>, options?: CookieSerializeOptionsExtended) => Promise<string>;
    getSession: (cookieHeader?: string | null, options?: CookieParseOptions & { isExtended?: boolean }) => Promise<Session<SessionData, SessionData>>;
}

type CookieSerializeOptionsExtended = CookieSerializeOptions & { isExtended?: boolean };

export const getSessionStorage = async (): Promise<IGetSessionStorageResponse> => {
    const { createCookieSessionStorage } = await import('@remix-run/node/dist/implementations.js');
    
    let sessionStorage = createCookieSessionStorage({
        cookie: {
            name: '_session', // use any name you want here
            sameSite: 'lax', // this helps with CSRF
             ... // add your cookie options here
        },
    });

    let sessionExtendedStorage = createCookieSessionStorage({
        cookie: {
            name: '_session-extended', // use any name you want here
            sameSite: 'lax', // this helps with CSRF
            ... // add your cookie options here
        },
    });

    const commitSession = (data: Session<SessionData, SessionData>, options: CookieSerializeOptionsExtended) => {
        if (options?.isExtended) {
            return sessionExtendedStorage.commitSession(data, options);
        }
        return sessionStorage.commitSession(data, options);
    }

    const getSession = (cookieHeader?: string | null, options?: CookieParseOptions & { isExtended?: boolean }) => {
        if (options?.isExtended) {
            return sessionExtendedStorage.getSession(cookieHeader, options);
        }
        return sessionStorage.getSession(cookieHeader, options);
    }

    const destroySession = (session: Session<SessionData, SessionData>, options?: CookieSerializeOptionsExtended) => {
        if (options?.isExtended) {
            return sessionExtendedStorage.destroySession(session, options);
        }
        return sessionStorage.destroySession(session, options);
    }

    return {
        commitSession,
        getSession,
        destroySession
    };
}