Storage: window.localstorage in createBrowserClient doesn't work

[tzvc]

Hey there,

I've been pulling my hair out because I want our app to authenticate users when loaded as iframe from a different source. Cookies seem to have a permission problem when trying to set them from a diff. domain so I thought i'd use localstorage for storing sessions instead:

Here's how I init my client on my NextJS 16 app:

"use client";
import { createBrowserClient } from "@supabase/ssr";
import { Database } from "../types/supabase";


export function getSupabaseClient() {
  return createBrowserClient<Database>(
    process.env.NEXT_PUBLIC_SUPABASE_URL as string,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY as string,
    {
      auth: {
        autoRefreshToken: true,
        persistSession: true,
        storage: typeof window !== "undefined" ? window.localStorage : undefined,
        debug: true,
      },
    }
  );
}

The issue is that no matter what I use in the custom storage, the session is still always stored in cookies.

What am I missing here?

[j4w8n]

For custom storage, you have to implement certain methods. If you look around the source code, you'll see what I mean.

It's not documented well, as far as I recall.

[tzvc]

@j4w8n Doesn't the localstorage class already implement all of them (getValue, setValue, etc...) ?

[j4w8n]

@tzvc

The default localStorage in the auth-js repo does, yes. But after looking at the ssr source code again, it ignores any custom storage you pass it. So, even if you did give it a proper implementation, it won't work. If you don't provide a cookies implementation, it defaults to using the document.cookie api and still stores things in cookies.

So, you'd need to use @supabase/supabase-js in order to get localStorage working. And in that case, there's no reason to use the ssr library.

[tzvc]

@j4w8n Is there a reason why storage is ignored in createBrowserClient ? Or is it just a bug?

So if want to store session in localstorage in my iframe I just have to use the "legacy" client switching from this:

import { createBrowserClient } from "@supabase/ssr";
import type { SupabaseClient } from "@supabase/supabase-js";
import type { Database } from "../../types/supabase";

export function createClient(): SupabaseClient<Database> {
    return createBrowserClient<Database>(
        process.env.NEXT_PUBLIC_SUPABASE_URL as string,
        process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY as string
    );
}

To this?

import { createClient as createSupabaseClient } from "@supabase/supabase-js";
import type { SupabaseClient } from "@supabase/supabase-js";
import type { Database } from "../../types/supabase";

export function createClient(): SupabaseClient<Database> {
    // chekc if is embed
    return createSupabaseClient<Database>(
        process.env.NEXT_PUBLIC_SUPABASE_URL as string,
        process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY as string,
        {
            auth: {
               // detect if running in embed
                storage: typeof window !== "undefined" && window.self !== window.top ? window.localStorage : undefined,
                autoRefreshToken: true,
                persistSession: true,
                detectSessionInUrl: true,
            },
        }
    );
}

[j4w8n]

It's not a bug, but by design. I think you used to be able to pass your own storage to the ssr clients though.

This code passes your options, including storage...

const { storage } = createStorageFromOptions(
    {
      ...options,
      cookieEncoding: options?.cookieEncoding ?? "base64url",
    },
    false,
  );

but createStorageFromOptions doesn't use storage:

export function createStorageFromOptions(
  options: {
    cookieEncoding: "raw" | "base64url";
    cookies?:
      | CookieMethodsBrowser
      | CookieMethodsBrowserDeprecated
      | CookieMethodsServer
      | CookieMethodsServerDeprecated;
    cookieOptions?: CookieOptionsWithName;
  },
  isServerClient: boolean,
) {
...

If you want to use localStorage with the @supabase/supabase-js clients, don't pass any of those options. If you don't pass storage it defaults to localStorage; and all the others you stated are the default values.

[tzvc]

I'm confused, If by design why accept storage in createBrowserClient if it doesn't do anything?

So if I understand correctly there is no way for me to use @supabase/ssr with anything else than cookie storage? So no way to use auth from inside an Iframe (that blocks third party cookies)?

[j4w8n]

There is no way to use localStorage directly with the ssr library, correct. But, you shouldn't need the ssr library if you're not using cookie storage, so just use the supabase clients from supabase-js to achieve what you want. You won't be able to use a server client to access the user's session though, since it obviously won't have access to the browser's localStorage - unless you somehow pass that to the server yourself.

ssr is accepting storage from a typescript perspective, because in the code they're using SupabaseClientOptions as part of the type union, which would include storage. (The ssr library does use other options that a dev might pass in). Perhaps they should consider doing an omit to filter out options that are a no-op.

options?: SupabaseClientOptions<SchemaName> & {
    cookies?: CookieMethodsBrowser | CookieMethodsBrowserDeprecated;
    cookieOptions?: CookieOptionsWithName;
    cookieEncoding?: "raw" | "base64url";
    isSingleton?: boolean;
  },

However, they overwrite any passed-in storage with their own storage built from the createStorageFromOptions code I referenced above.

auth: {
      ...options?.auth,        // YOUR CUSTOM STORAGE SPREAD HERE !!!!!!!!
      ...(options?.cookieOptions?.name
        ? { storageKey: options.cookieOptions.name }
        : null),
      flowType: "pkce",
      autoRefreshToken: isBrowser(),
      detectSessionInUrl: isBrowser(),
      persistSession: true,
      storage,                 // BUT THEY OVERRIDE IT HERE !!!!!!!!
      ...(options?.cookies &&
      "encode" in options.cookies &&
      options.cookies.encode === "tokens-only"
        ? {
            userStorage: options?.auth?.userStorage ?? window.localStorage,
          }
        : null),
    },