@supabase/ssr updates and roadmap towards v1.0.0

[hf]

Go here for latest update

Hey everyone,

I'm Stojan a member of the Supabase Auth team, bringing some updates about what's next with @supabase/ssr. This is the recommended package that helps you use the Supabase JavaScript client with SSR frameworks such as NextJS, Remix, SvelteKit and others.

We've been quite busy recently gathering feedback, reviewing common complaints and bugs with the package, and using it in the popular SSR frameworks. We've identified a few areas needing improvement and we've already started implementing them.

The package is still on major version 0, indicating its beta status. We plan to move it to major version 1 in the coming months making it the preferred way of using the Supabase JavaScript library in your favorite SSR framework.

First, we'll extract @supabase/ssr's code from the auth-helpers repository into its own. We’re doing this because:

• @supabase/auth-helpers-x (like for NextJS) is no longer supported by the team, as we expect people to move to @supabase/ssr.
• It's no longer about "auth-helpers," but rather about how you can most effectively and ergonomically use the Supabase Client in various SSR and CSR contexts.
• A standalone repo makes it easier for the community to contribute and for us to track issues.

We're going to release a fairly ground-up reimplementation of the package. This should come as version 0.4.0 around mid-June. We've received a lot of signal in the past months from developers and the community about possible improvements for developer ergonomics and better handling for edge cases.

The reason for this change is because @supabase/ssr is really just a thin layer for cookie management on top of @supabase/supabase-js. We've identified some improvements that reduce odd and difficult-to-diagnose behavior. The new implementation will boast over 90% test coverage, including testing for issues that we’ve seen commonly reported so far.

As part of the new implementation, we are changing the API. The old API will be deprecated when we reach v1.0.0. This is to ensure the best possible experience for both developers and users. For most use cases and happy paths, the deprecated API will continue working during the phase-out, but we encourage switching as soon as possible. Once we release v1.0.0, major version 0 will no longer be maintained.

The change in the API is quite simple, so here’s an example of how it will look like. Instead of defining three cookie access methods get, set and remove like so:

createServerClient(SUPABASE_URL, SUPABASE_ANON_KEY, {
	cookies: {
		get: async (name) => {
			// ...
		},
		set: async(name, value, options) => {
			// ...
		},
		remove: async(name) => {
			// ...
		}
	}
})

You would need to define two — getAll and setAll cookie access methods like so:

createServerClient(SUPABASE_URL, SUPABASE_ANON_KEY, {
	cookies: {
		getAll: async() => {
			// return all cookies you have access to
		},
		setAll: async(cookiesToSet: { name: string; value: string; options: CookieOptions; }[]) => {
			// set the cookies exactly as they appear in the cookiesToSet array
		}
	}
})

Note that for createBrowserClient nothing needs to be done in most cases, it automatically works with the document.cookie API.

The change should be trivial for most SSR frameworks, and we'll be sure to update the guides to instruct you on how to change your code into this new way of accessing cookies.

Thanks for all your feedback! Feel free to ask any questions below!

[dac09]

Any chance we could have a function to get the name of the cookie too? This is something we've had to workaround in order to remove the cookie from any request on decryption failure for example.

[dac09]

Sure, this is what we're doing to clear the cookie. I believe the .remove method would only get called if we did a logout - which would make an API request to supabase

https://github.com/redwoodjs/redwood/blob/main/packages/auth-providers/supabase/middleware/src/util.ts#L59-L77

This function is used in this line here - where essentialy we are saying if decryption (or the following steps to set the auth state fails) - clear the cookie.

Please do let me know if there's a better way to do this already though ✌️

[hf]

Oh! So if I understand correctly you need a way to clear all Supabase-related cookies?

[dac09]

Thats right 👍

[hf]

OK I'll try to find some way to get you that! Will post here soon!

[dac09]

Hi @hf just putting this back on your radar :)

[silentworks]

You should open a new topic on this as it has no relation to the post above.

[MuyiwaJohnson]

my bad. thanks

[activenode]

I'm seeing it as a major improvement to have it in its own repo as well as removing the rather redundant remove option.

However, having seen struggling users with the existing ssr package just a little bit, I felt that getCookie and setCookie were less confusing than getAll and setAll.

Another thing is that given separation of concerns I don't really like a foreign library to grab all my cookies and be able to iterate those. It's not like you couldn't access all my cookies with the previous version but it was less intrusive as you couldn't iterate through them (you don't know the cookies, you can only bruteforce the keys).

Concluding:

• I'm fine with setAll as it really doesn't make a big difference for me but then again set() was extremely straight forward, no matter which cookie utils (next, vue, you name it), set() could be forwarded with mostly one simple line of code.
• I'd be struggling with implementing getAll() as I don't see a huge benefit

[activenode]

The only way I'd be able to build my separation of concerns would be to give you a subset of my cookies - which is additional work so the new version would add work for us.

[hf]

Yeah unfortunately we need a way to see all cookies so we can do chunk management correctly. This cannot be done without something like getAll. We can add docs about how to filter out some of the cookies if that's a big concern, but I don't see it that way. Any JavaScript that you run on your site be it in browser or NextJS can read the cookies, local storage, everything.

[activenode]

not true on the server but true on the client-side so you got a valid point; agreed, overruled. Yeah I think one that does need "filtering" for whatever reason knows how to do that I guess. No need for docs on that one.

But what about using setCookie instead of setAll ? I found that to be the most convenient way

[hf]

Because of the way setting cookies in middleware works, it's best if the "instruction" from the ssr library to the framework on setting cookies to be in one-go. One very serious problem there is currently, as our guides explain:

createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        get(name: string) {
          return request.cookies.get(name)?.value
        },
        set(name: string, value: string, options: CookieOptions) {
          request.cookies.set({
            name,
            value,
            ...options,
          })
          response = NextResponse.next({
            request: {
              headers: request.headers,
            },
          })
          response.cookies.set({
            name,
            value,
            ...options,
          })
        },

In here, if set is called multiple times, the response object is being overwritten and it turns out that only the last cookie to be set is being set. The simplest way we could find to make this DX a lot better is to use setAll. Otherwise, you will be faced with a lot of lines of code copying cookies and headers on each set call -- unnecessary and very easy to mess up accidentally -- ending up in random logouts or worse.

[jdgamble555]

I wonder if it would be better to rewrite getSession and getUser to be one function. getSession automatically calls getUser when there is a session, and handles all that confusion under the hood. Otherwise, if necessary, have a use-unsafe-session flag for possible edge cases?

Just spit balling.

J

[activenode]

this would be a breaking change which I wouldn't recommend for people that deliberately use getSession for what it is right now.

Also, getUser afaik does call getSession so if this was implemented you'd have 2 functions doing the same thing.

I agree however on the aspect that maybe deprecating getSession longterm and calling it getUnsafeSession instead can be helpful

[hf]

We are not planning on making any breaking changes at all for now with regards to @supabase/auth-js (formerly @supabase/gotrue-js). We are going to be exploring other ergonomics for @supabase/ssr to help you deal with authorization in NextJS middleware more securely.

[om154]

Thanks for the update. My team and I have been working on migrating to @supabase/ssr from the NextJS helpers library.

Overall, would you suggest migrating from @supabase/auth-helpers-x to @supabase/ssr version 0 today, or waiting until the package is out of beta and v1.0.0 is published?

[om154]

Great! Thanks for the insight

[om154]

@hf any further insight on timeline for v1.0.0?

We have a (huge 😆 ) branch migrating auth helpers to @supabase/ssr, including the changes in v0.4.0. We're just apprehensive about merging and beginning to use the updated library in production until v1.0.0 is officially published.

[j4crev]

@om154 they are targeting some time in August.

If you decided to not wait, make sure you use 0.4.1 or up

[JayP127]

Will the v1.0.0 be tested for Remix?

[silentworks]

@JayP127 current version works with Remix, so I can't see why 1.0.0 wouldn't.

[chanmathew]

Hi folks, not directly related but I think still relevant, what is the recommended package to use now for SPAs or mobile apps?

For example I’m using Sveltekit, and compiling to mobile using CapacitorJS. With the whole SSR package transitions I’m finding it very confusing what is the “right way” to implement auth. There’s now the auth helpers, the SSR package, and also this new PKCE flow.

Also I’ve really struggled to find documentation on how deep linking (without universal links) would work for mobile apps using magic link sign in to direct users from the email back to the app. The docs are focused for Expo and Flutter but seems to not be clear for a non-specific framework and just “vanilla” mobile apps.

Just wanted to share that feedback and hope to get some clarity. Appreciate all the great work you guys are doing at Supabase!

[hf]

Probably worthy of a separate discussion. Here's some notes to unblock you:

what is the recommended package to use now for SPAs or mobile apps?

That remains @supabase/supabase-js. If you plan on introducing a SSR framework in the future, you can also only use createBrowserClient from @supabase/ssr which is really just supabase-js with cookie support.

[harrisrobin]

@hf when using createBrowserClient, typescript complains about the signature lacking setAll and getAll, however from my understanding createBrowserClient automatically works with document.cookie API correct?

If so, would it be possible to remove the deprecation warning for it?

[j4crev]

@harrisrobin do you mind creating an issue for that on https://github.com/supabase/ssr/issues? I was able to reproduce it. I originally had no issues with my SvelteKit implementation, but that's because we add { global: { fetch } } as part of the supabase client options. When I removed that, I got the same thing as you. But it goes away when you add an empty object - createBrowserClient(url, key, {})

[hf]

I will address it, no need for an issue.

[hf]

supabase/ssr#17

[hf]

Hey everyone! We've finished internal tests on the new changes and have prepared a release candidate for you.

I would love to get some early feedback. Please don't use the release candidate in production just yet. Let's give it a week or so to marinate and gather feedback before we publish it.

RC versions published so far:

• 0.4.0-rc.2

I will update and link to the new docs for each framework soon.

[therealsujitk]

@hf it is required by SvelteKit (source), adding that as a default option would be nice, yes.

[j4crev]

@j4w8n Saw this:

            event.cookies.set(name, value, { ...options, path: '/' })

In your code. I can add the path: '/' as a default option if that's important for SvelteKit. Let me know!

@hf, adding path: '/' by default would go against why SvelteKit ultimately decided to require that setting. From what I can tell, the TL;DR is that having it be a default was deemed insecure, despite '/' typically being what devs want anyway, and buggy for the framework. Of course, Supabase is obviously welcome to do what they'd like, I just wanted to give you some context. Here is the PR, with it's own discussion, and a link to the original discussion, if you're curious: sveltejs/kit#9299

[j4crev]

I could be wrong, but Supabase making it default may not help because SvelteKit's typing wants to see path for that method.

UPDATE: I guess Supabase would just type options to include path.

[hf]

Hmm ok thanks for this. I'll think about it, it works either way.

[silentworks]

As @j4w8n mentioned this should be left to the developer to implement, the guides can make mention of it but it shouldn't be a default the the ssr package in my opinion.

[uncvrd]

Thanks for working on this! I have a request that could hopefully find its way into the package...

I need to send headers with my client requests. To do that I have configured the following:

export function createClient(orgContactId: string | null) {
    const supabase = createBrowserClient<Database>(env.NEXT_PUBLIC_SUPABASE_PROJECT_URL, env.NEXT_PUBLIC_SUPABASE_ANON_KEY, {
        cookies: {},
        cookieOptions: {
            domain: env.NEXT_PUBLIC_APP_DOMAIN,
        },
        global: {
            headers: {
                "org-contact-id": `${orgContactId ?? ""}`,
            },
        },
        isSingleton: false,
    })

    return supabase
}

However the issue is that I can't update this header after the client is created so if the orgContactId changes, I need to create a completely new client

I do that by taking the "singleton" in to my own hands and when I detect an ID change, I create a new client that has the new header

export let supabaseBrowserClient: SupabaseClient<Database> | null = null
let orgContactId: string | null = null

export function getSupabaseBrowserClient(activeOrgContactId: string | null) {
    if (supabaseBrowserClient && activeOrgContactId === orgContactId) {
        return supabaseBrowserClient
    }

    orgContactId = activeOrgContactId
    supabaseBrowserClient = createClient(activeOrgContactId)

    return supabaseBrowserClient
}

function useSupabaseBrowser() {
    const {
        userPreference: { activeOrgContactId },
    } = useAppStore((store) => store)

    return useMemo(() => getSupabaseBrowserClient(activeOrgContactId), [activeOrgContactId])
}

The downside to this is that I get warnings in my console stating there are now multiple clients created and that I may deal with unintended behavior.

I would love to be able to just simply update the headers in the client after it's created...if possible.

Hope you see the use case for it, let me know if you have any other questions :)

[hf]

@uncvrd Can you please open an issue for this on https://github.com/supabase/supabase-js

[uncvrd]

@hf oh sure, I'll do that. I guess I thought this would be the place to ask since I'm using 'createBrowserClient' from the ssr package. Sorry!

[alrightsure]

Does this new implementation still require pinging the Supabase servers on every request? I've noticed a significant increase in page load times due to this limitation when using SSR with Supabase.

[vickkhera]

@hf any cryptographical methods for verifying such a session without the need to check if the user still exists?

You can cryptographically validate the JWT. However, the user bits live outside that. The JWT will be valid for as much time as you configured it to be so (default I think is 1 hour). That doesn't prove anything other than at the time of issue, that user ID was checked against the database as still valid and the contents within it are unaltered. Any JWT decoder can do it and validate the signature given the JWT secret from your dashboard. Just make sure you don't do that in the browser side.

To explain what I mean by the user bits living outside the JWT, from my test suite I have a bit of code that synthesizes a user session:

function synthesize_supabase_jwt (user_id: string) {
  const supabase_jwt_secret = 'super-secret-jwt-token-with-at-least-32-characters-long';  // the local dev environment uses this
  const jwtPayload = {
    sub: user_id,
    aud: "authenticated",
    role: "authenticated",
    is_anonymous: false,
    email: user_login_email,
    user_metadata: {},
    app_metadata: {"provider": "email", "providers": ["email"]},
  };

  return jwt.sign(jwtPayload,supabase_jwt_secret,{ algorithm: 'HS256', issuer: "http://localhost:54321/auth/v1", expiresIn: "15m" });
}

export function run_with_supabase_client<T>(fn: () => T): T {
  const cc = {
    access_token: synthesize_supabase_jwt(user_id),
    token_type: 'bearer',
    expires_at: Math.trunc(Date.now() / 1000 + 60 * 15),
    refresh_token: "x",
    user: {id: user_id},  // we only use this field in the login/logout debugger line
  };
  const request = new Request('http://localhost', {
    headers: new Headers({
      Cookie: `sb-localhost-auth-token=${JSON.stringify(cc)}`
    })
  });
  return supabase_run_with_client(request, fn);
}

The function at the end uses the ssr package to create the server client with the Request object I just synthesized and runs the given function. The only thing signed here is the JWT, and that doesn't protect anything in the user part of the session as you can see. I can put in there anything I want. That's why you don't want to trust it for anything affecting privileges when calling getSession() since it just passes it through.

Now, if we could have a shared encryption secret to crypt the whole cookie itself, we could trust it. But Supabase auth doesn't do that.

[hf]

We are working on asymmetric JWTs that will give you a different way to authorize users without pinging the server unnecessarily. This is not part of this version, and probably will be available around v1.0.0.

The only thing signed here is the JWT, and that doesn't protect anything in the user part of the session as you can see. I can put in there anything I want.

Of course. We are not using cookie-based authentication, so the cookies will never be signed. There will only be getUser() which does a request and something similar to getClaims() (method name and DX being currently explored) which will check the signature of the JWT and give you back the claims for authorization.

Most use cases should only use this new getClaims() method. Unfortunately https://github.com/supabase/auth-js v2 was not designed with any SSR use case in mind as it was released just a few months before SSR became popular.

We explicitly decided not to add getClaims() before we have asymmetric JWTs because it's very easy to accidentally leak the shared secret in the browser. However to add asymmetric JWT support requires a massive amount of work on the Supabase platform that took around 2 months and is still ongoing in some respects.

We are aware of the limitations and are doing everything we can to make fix it ASAP, but it's really a lot of moving parts.

[activenode]

@vickkhera My question was targeted to "verify" but if I'm not mistaken, your code sample just shows the getSession() behaviour which we have. If that synthesized session was verified with the secret, the data within, for the time being trusted at user session creation, should be trustworth (as being verified via JWT) - or am I missing a point?

[vickkhera]

@vickkhera My question was targeted to "verify" but if I'm not mistaken, your code sample just shows the getSession() behaviour which we have. If that synthesized session was verified with the secret, the data within, for the time being trusted at user session creation, should be trustworth (as being verified via JWT) - or am I missing a point?

My point was to show with code how one can synthesize the session data completely un-verified when using a cookie for session storage. When writing my test cases it became 100% obvious how that data is unprotected. Only the data inside the decoded JWT can be trusted from that cookie. The copied data in the rest of the cookie is open to tampering.

[activenode]

I mean that's very clear but that's not what I was asking or pointing out. You can even just manipulate it manually in the browser and it will take that. All it does is "loading whatever there is". But this wasn't my question. But it might help someone else, so thanks.

My question was: Can we verify the unverified JWT and obviously we can given the JWT secret. It was also more of a rhetoric pitfalls-to-consider question

[itsmikesharescode]

Any update on this??

This give me an extreme anoyance

[hf]

Nope, this is not a discussion for this.

[kvetoslavnovak]

Yes, this is super annoying. To follow official docs & best practices just to be bombarded by zilliions of warning logs later on how insecure our code could be.

[activenode]

I took RC5 to migrate and didn't change the createBrowserClient which looks like this now:

export const getSupabaseBrowserClient = () =>
  createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
  );

The interesting part is that it is NOT used in a server-environment but in a NextJS use client' - which obviously will run once on the server for pre-rendering. So I'm a bit unsure how to avoid this error or what's your best proposal really because it will work (as it does not trigger anything when it only server-renders).

Sure, the workaround would be to only instantiate it when used but since it's used in multiple functions defined below, I wanted to instantiate it in the Component - which didn't throw an error before the change.

Any proposals?

Proposal:
My proposal: When using createBrowserClient, don't execute anything and stay silent or at most throw a warning if typeof window === undefined ?

[activenode]

Thanks, I'm aware of potential workarounds (in fact, none is needed as it will not fail anyways since I don't do anything on the server with the browser client). Was just trying to figure out how to best handle it with the new package but added a proposal in my edit now, see above :)

Thanks anyway!

[activenode]

Looking at the source code I'm wondering why the error message even exists since it's in the `else` which means browser client. Maybe just remove it or as I said: Give a warning like `console.warn('Info: createBrowserClient was executed in non-browser context.', callStack)`

[hf]

I'll see what we can do... maybe return null.

[hf]

Think I found this nice compromise. What do you think?

supabase/ssr#20

[activenode]

supabase/ssr#20 (comment)

[hf]

Version 0.4.0 is published!

Who needs to upgrade:

• Pretty much everyone.
• Make sure you move to getAll and setAll as soon as you are able. This is especially important for Next.js users inside their middleware.ts file. This is the biggest source of problems, and this update significantly reduces the issues!

Example guides have been updated:

• Next.js
• SvelteKit
• Astro
• Remix

In this release the encoding of the session has changed to Base64-URL. Downgrading back to v0.3.0 is really discouraged, and will result in users being logged out. But that's expected, because 0.3.0 has significant issues which is why this effort was necessary.

[arianaamx]

I think the solution for multiple requests to auth server would be React Cache: https://react.dev/reference/react/cache

That way you would extract the getUser call to its own file, wrap it inside cache, and call that function where you need it (inside Server components). It should then take the response from cache, and not call it the second/third time.

[empz]

Caching auth? That certainly doesn't sound like a good idea to me. Besides, supabase getUser() doesn't take any argument. React's cache need a different argument for each user (otherwise user A could be getting a cached response for user B).

[mnalley95]

I'm getting the following error when migrating my OAuth Flow. i've tried variations of @empz, @pariah140, and @dabbijak 's recommendations:

 ⨯ Error [AuthApiError]: invalid request: both auth code and code verifier should be non-empty
    at handleError (webpack-internal:///(rsc)/./node_modules/.pnpm/@supabase+auth-js@2.64.2/node_modules/@supabase/auth-js/dist/module/lib/fetch.js:74:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async _handleRequest (webpack-internal:///(rsc)/./node_modules/.pnpm/@supabase+auth-js@2.64.2/node_modules/@supabase/auth-js/dist/module/lib/fetch.js:117:9)
    at async _request (webpack-internal:///(rsc)/./node_modules/.pnpm/@supabase+auth-js@2.64.2/node_modules/@supabase/auth-js/dist/module/lib/fetch.js:99:18)
    at async SupabaseAuthClient._exchangeCodeForSession (webpack-internal:///(rsc)/./node_modules/.pnpm/@supabase+auth-js@2.64.2/node_modules/@supabase/auth-js/dist/module/GoTrueClient.js:420:33)
    at async eval (webpack-internal:///(rsc)/./node_modules/.pnpm/@supabase+auth-js@2.64.2/node_modules/@supabase/auth-js/dist/module/GoTrueClient.js:741:28)

my middlware is:

import { createServerClient } from '@supabase/ssr'
import { NextResponse, type NextRequest } from 'next/server'

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({
    request,
  });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              request.cookies.set(name, value),
            );
            supabaseResponse = NextResponse.next({
              request,
            });
            cookiesToSet.forEach(({ name, value, options }) =>
              supabaseResponse.cookies.set(name, value, options),
            );
          } catch (error) {
            console.error(error);
            debugger;
          }
        },
      },
    },
  );

  // IMPORTANT: Avoid writing any logic between createServerClient and
  // supabase.auth.getUser(). A simple mistake could make it very hard to debug
  // issues with users being randomly logged out.

  const {
    data: { user },
  } = await supabase.auth.getUser();

  const ALLOWED_ANONYMOUS_PATHS = ["/login", "/signin", "/auth/callback", "/", "/signin/oauth_signin", "api/auth/callback", "/signin/"];

  if (!ALLOWED_ANONYMOUS_PATHS.includes(request.nextUrl.pathname) && !user) {
    // no user and path does not allow anonymous access, redirect to login
    const url = request.nextUrl.clone();
    url.pathname = "/signin";
    return NextResponse.redirect(url);
  }

  // IMPORTANT: You *must* return the supabaseResponse object as it is. If you're
  // creating a new response object with NextResponse.next() make sure to:
  // 1. Pass the request in it, like so:
  //    const myNewResponse = NextResponse.next({ request })
  // 2. Copy over the cookies, like so:
  //    myNewResponse.cookies.setAll(supabaseResponse.cookies.getAll())
  // 3. Change the myNewResponse object to fit your needs, but avoid changing
  //    the cookies!
  // 4. Finally:
  //    return myNewResponse
  // If this is not done, you may be causing the browser and server to go out
  // of sync and terminate the user's session prematurely!
  return supabaseResponse;
}

my /auth/callback/ route:

import { createClient } from '../../../utils/supabase/server';
import { NextResponse } from 'next/server';
import { NextRequest } from 'next/server';
import { getErrorRedirect } from '../../../utils/helpers';
import { type CookieOptions, createServerClient } from '@supabase/ssr'

import { cookies } from 'next/headers'

export const runtime = 'edge';

export async function GET(request: NextRequest) {
  const requestUrl = new URL(request.url);
  const { searchParams, origin } = new URL(request.url)
  const code = searchParams.get('code')

  if (code) {
    const supabase = createClient()

    const { error } = await supabase.auth.exchangeCodeForSession(code);

    if (error) {
      return NextResponse.redirect(
        getErrorRedirect(
          `${requestUrl.origin}/signin`,
          error.name,
          "Sorry, we weren't able to log you in. Please try again."
        )
      );
    }
    if (!error) {
      const { data: { user }, error: userError } = await supabase.auth.getUser();
      if (user && user.id) {
        const { data: subscription, error } = await supabase
          .from("subscriptions")
          .select(`status`)
          .eq("user_id", user?.id)
          .in("status", ["active", "trialing"])
          .maybeSingle();

        const isSubscribed = subscription && (subscription.status === "active" || subscription.status === "trialing");

        return isSubscribed
          ? NextResponse.redirect(`${requestUrl.origin}/chat`)
          : NextResponse.redirect(`${requestUrl.origin}/pricing`);
      } else {
        return NextResponse.redirect(`${requestUrl.origin}/pricing`);
      }

      return NextResponse.redirect(`${requestUrl.origin}/chat`);
    }
  }
}

[empz]

Version 0.4.0 is published!

Who needs to upgrade:

• Pretty much everyone.
• Make sure you move to getAll and setAll as soon as you are able. This is especially important for Next.js users inside their middleware.ts file. This is the biggest source of problems, and this update significantly reduces the issues!

Example guides have been updated:

• Next.js
• SvelteKit
• Astro
• Remix

In this release the encoding of the session has changed to Base64-URL. Downgrading back to v0.3.0 is really discouraged, and will result in users being logged out. But that's expected, because 0.3.0 has significant issues which is why this effort was necessary.

I see there's a new 0.5.0 version. Where's the latest documentation for it? Are the official docs up to date?
https://supabase.com/docs/guides/auth/server-side

[j4crev]

@empz docs should be good for the latest version.

[atsakiridis]

On the migration path from auth-helpers to ssr it seems like its no longer possible to get notified on the client of events like 'TOKEN_REFRESHED' with supabase.auth.onAuthStateChange() and usage of react context is discouraged/not applicable. Is this deliberate or something that you plan to change as you get closer to 1.0?

I can understand the SDK simplicity of using the same (singleton) client for every route but it feels like DX might suffer

[XStarlink]

Thanks for your answers, I understand that without the code it's difficult to identify the cause, but I'm not doing anything special apart from using the @nuxt/supabase library.
I think you probably already have a lot of things to manage and follow, but if you could just take a quick look at its implementation to be able to tell if it looks good to you, that would help me a lot because I've been doing a lot of research around auth supabase for weeks but there are really a lot of things that aren't easy to know even after having read the doc 5 times, like for example what you say just above about the fact that in PKCE it doesn't use onAuthStateChanged, I didn't know that..

I had already opened an issue on the @nuxt/supabase module but it was closed a little prematurely in the last release, thinking that switching to @supabase/ssr would solve my problem, but I'll have to reopen it I guess, and if Supabase need more info or investigation I'll open an issue directly on this lib.

In any case, thank you for your advice and your work

[j4crev]

@XStarlink Having that issue reopened might be your best bet.

I also recall the Nuxt module's owner trying to update it to use ssr, but I'm not sure where they landed with that.

You might post about your issue on the Supabase Discord server. I'd suggest lowering your JWT expiry time to 120 seconds to expedite testing, but since this is production, it could worsen things for your user. Being able to troubleshoot on a different Supabase project is ideal.

I know a good amount about how Supabase auth works, just not familiar with the Nuxt module. But I'm happy to help however I can.

[XStarlink]

@activenode, when you say:

Even with the auth helpers: If one went full PKCE, one wouldn't have seen a TOKEN_REFRESHED in the client as it happened on the server.

I'm trying to understand how session refresh works when using PKCE.

@activenode, @j4w8n I have a few questions if you don't mind:

1. @nuxt/supabase has moved from supabase-js to supabase/srr, is the ssr version supposed to work even if I have my nuxt app configured in SPA, i.e. without SSR?

2. Where does the token refresh take place? Directly in the lib without the user having to do anything?

3. Depending on where the Supabase client is used in a web framework, could the code inside the client no longer be automatically executed? Or is this not possible, and is it always supposed to work on its own, regardless of whether the client is loaded into a plugin / composable / front-end / module?
   Is it normally supposed to work even when you leave a tab untouched for several days and then come back and you're still supposed to be connected?

4. In Supabase, what defines that a session must be deleted from the auth.sessions table? An inactivity timeout? A refresh token error in the supabase lib?

5. Before with supabase-js I had in my cookies an access-token and I could put it in jwt.io to see its content, now with supabase/ssr I have an auth-token in base 64 and when I decode it I don't get any text but just special characters, how can I see its content now?

Thank you very much for your feedback and help, I'm determined to find the problem.

[j4crev]

@activenode, when you say:

Even with the auth helpers: If one went full PKCE, one wouldn't have seen a TOKEN_REFRESHED in the client as it happened on the server.

I'm trying to understand how session refresh works when using PKCE.

@activenode, @j4w8n I have a few questions if you don't mind:

1. @nuxt/supabase has moved from supabase-js to supabase/srr, is the ssr version supposed to work even if I have my nuxt app configured in SPA, i.e. without SSR?

2. Where does the token refresh take place? Directly in the lib without the user having to do anything?

3. Depending on where the Supabase client is used in a web framework, could the code inside the client no longer be automatically executed? Or is this not possible, and is it always supposed to work on its own, regardless of whether the client is loaded into a plugin / composable / front-end / module?
   Is it normally supposed to work even when you leave a tab untouched for several days and then come back and you're still supposed to be connected?

4. In Supabase, what defines that a session must be deleted from the auth.sessions table? An inactivity timeout? A refresh token error in the supabase lib?

5. Before with supabase-js I had in my cookies an `access-token` and I could put it in jwt.io to see its content, now with supabase/ssr I have an auth-token in base 64 and when I decode it I don't get any text but just special characters, how can I see its content now?

Thank you very much for your feedback and help, I'm determined to find the problem.

I'd encourage you to start a new discussion, or a post on the Discord server, for any further questions about how things are working; but I'll try to answer the questions you've posed:

1. I'm not sure; this might be better asked on the nuxt module repo

2. The default behavior is for this to happen automatically by the auth-js library (installed as part of supabase-js).

3. Not sure if you meant to number these separately.
   a. "Depending on where the Supabase client is used in a web framework, could the code inside the client no longer be automatically executed? Or is this not possible, and is it always supposed to work on its own, regardless of whether the client is loaded into a plugin / composable / front-end / module?" I'm not sure where you're going with this, but there are certain functionalities you can turn off for the supabase client. Otherwise, things are typically taken care of. However, I'm not familiar with how the Nuxt module works.

   b. Yes, leaving a tab or even closing a browser should not be an issue. I recently logged into my demo app, then put my pc to sleep (or shut it down, don't recall), went on vacation for a week, came back, and I was still logged-in when I loaded the site back up.

4. Removing a session from auth.sessions is triggered when a user logs out or is deleted. There could be other scenarios that I'm not aware of.

5. You just need to get rid of the base64- at the beginning, then the entire session will show up on jwt.io and reveal the value of the access_token; then from that output you can copy the access token value into jwt.io.

[XStarlink]

@j4w8n Thanks so much for your help and replies, I'll start a new discussion so I won't keep posting here.

[curiosbasant]

I already have a response object created, so do you think this implementation is correct?

export function getSupabaseMiddleware(request: NextRequest, response: NextResponse) {
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll()
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach((c) => request.cookies.set(c.name, c.value))
          // Specially this part?
          for (const pair of request.headers) {
            response.headers.set(...pair)
          }
          cookiesToSet.forEach((c) =>
            response.cookies.set(c.name, c.value, c.options),
          )
        },
      },
    },
  )
}

[activenode]

In theory should work. Practically, didn't check. you can also pass a responseRef instead. That's what I do. Then do responseRef.response = NextResponse.next.... and you're cool

[itsmikesharescode]

what now should i abort using ssr for now and find diff solutions?

[j4crev]

Technically, the new docs will use (cookiesToSet) => instead of (cookies) =>. Use whichever you'd like.

cookies: {
  getAll: () => event.cookies.getAll(),
  setAll: (cookies) => {
    cookies.forEach(({ name, value, options }) => {
      event.cookies.set(name, value, { ...options, path: '/' })
    })
  }
}

[itsmikesharescode]

do you have the new docs link?

[j4crev]

The last I saw, they were there for Next, but there was some kind of snafu for SvelteKit. I assumed they would've fixed it by now. It'll just be the normal auth guides for ssr

[j4crev]

If you didn't already see, someone pointed out that the creating a client page has updated docs for SvelteKiit, just not the guide.

#27037 (reply in thread)

[stevengrimaldo]

im getting the following issue having updated to the 0.4.0 following the latest Next.js docs you updated:

Error: Cookies can only be modified in a Server Action or Route Handler. Read more: https://nextjs.org/docs/app/api-reference/functions/cookies#cookiessetname-value-options

[luke-concannon]

Wrap the logic inside your setAll() with a try catch and manage the error graceful, then your app can do its thing. The supabase client must be calling setAll() in server components, where cookies() are read-only.

[stevengrimaldo]

Wrap the logic inside your setAll() with a try catch and manage the error graceful, then your app can do its thing. The supabase client must be calling setAll() in server components, where cookies() are read-only.

im making an initial call in my layout.tsx file where i have a navbar added with user info i grab from supabase

[empz]

I'm having the same issue. I'm not calling createClient from a client component, but I'm indeed calling it inside a layout (app/dashboard/layout.ts).

[ErikPetersenDev]

@stevengrimaldo , @empz

I was just helping someone else with this error and it turned out they were missing a line in their middleware's version of the setAll function (supabaseResponse = NextResponse.next({ request })).

        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) => request.cookies.set(name, value))
          supabaseResponse = NextResponse.next({ request }) // This was missing
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          )
        },

I removed that line from my code and got the "cookies can only be modified" error 100% of the time on token refreshes. What was happening in their case was that a token refresh happened correctly in middleware and a new token was set in the response. But since that line was missing the request to the server still had the old token. That caused a second token refresh on the server (refresh would succeed since the refresh token can be used multiple times within 10 seconds, but the cookie write would fail). The response still properly returns/sets the new cookie in the browser, so going to the page again works normally and the error is gone (until the next refresh, at which point it'll happen exactly once again).

Anyway, thought I'd mention it in this thread as well in case it helps anyone else.

[stevengrimaldo]

yes! unironically after i sent my last message i noticed that and you're exactly right! that fixed it up for me thanks!

[ham-evans]

[activenode]

Without knowing how your code looks, it's pretty hard to tell what your problem is. Cheers - activeno.de

[grehnen]

Using SvelteKit I still get an error, and I cant even get my app to open in the browser:

It appears src/routes/+layout.ts is where the fault is:

When I check step 5 in the ssr-guide for SvelteKit, it looks just like in my file, so I assume the guide hasn't been updated completely yet.

What is the correct solution?

[grehnen]

Technically, the new docs will use (cookiesToSet) => instead of (cookies) =>. Use whichever you'd like.

cookies: {
  getAll: () => event.cookies.getAll(),
  setAll: (cookies) => {
    cookies.forEach(({ name, value, options }) => {
      event.cookies.set(name, value, { ...options, path: '/' })
    })
  }
}

I used this solution in src/hooks.server.ts, haven't really been able to check if it works though. The guide still isn't updated for that file either.

[grehnen]

Found a repo with this solution for src/routes/+layout.ts further up in the discussion with this solution: Link to file

export const load = async ({ fetch, data, depends }) => {
  depends('supabase:auth')

  const supabase = isBrowser()
    ? createBrowserClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
        global: { fetch }
      })
    : createServerClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
        global: { fetch },
        cookies: {
          getAll() { 
            return data.cookies
          }
        }
      })

  const session = isBrowser() ? (await supabase.auth.getSession()).data.session : data.session

  return { supabase, session }
}

My app is running fine now, shoutout @j4w8n! Putting this here in case others are also struggling with migrating their SvelteKit projects. (Still haven't been confirmed by Supabase team though)

[j4crev]

Glad you got it working. And yes, the SvelteKit guide was supposed to be updated, but for some reason the site is not reflecting that.

Regarding what the guide will show, once it's up, there is a difference between what it's saying to do and what I actually do. You'll find that in the new guide's layout.ts file, it still uses the legacy get method and stringifies data.session for the server client. Whereas I thought we were supposed to move away from that, so I return all of the cookies from layout.server.ts and do as you see in the code above, with getAll returning data.cookies. I'm not sure what the best answer is, I was just trying to fully deprecate get.

[j4crev]

And to be honest, I'm assuming that as long as you're not using the supabase client for anything on the server side of layout.ts or layout.svelte, then you can probably just return null for the getAll method and not mess with passing the cookies in from layout.server.ts. I just wanted my repo to assume that someone would want to use it in some form.

[magick93]

I'm eagerly awaiting the sveltekit docs to land and confirmation it is working and makes sense!

[magick93]

Not ok. But anyway...

[dfsmatador]

Yeah, I'm waiting as well. I'm new to the Supabase ecosystem, and now I'm very lost because the documentation for Sveltekit is all over the place, and there are no "published at" dates/indicators to help me figure out which patterns work together. I'm trying to use this highly recommended SSR package with a PKCE flow, but the documentation and tutorials are leading me astray, ironically.

[j4crev]

If you didn't already see, someone pointed out that the creating a client page has updated docs for SvelteKiit, just not the guide.

#27037 (reply in thread)

[dfsmatador]

Thanks @j4w8n! I've been reading through your repo above, and it is incredibly helpful.

[silentworks]

I've opened a PR to update the guides. So this will be in the official guides soon. #27641

[magick93]

I've just tried to update my Sveltekit application to use SSR 0.4.0. I'm following the docs on https://supabase.com/docs/guides/auth/server-side/creating-a-client?framework=sveltekit

I'm getting the following concerning errors:

@supabase/ssr: createServerClient was configured without the setAll cookie method, but the client needs to set cookies. This can lead to issues such as random logouts, early session termination or increased token refresh requests. If in NextJS, check your middleware.ts file, route handlers and server actions for correctness.
AuthApiError: error finding refresh token: ERROR: column refresh_tokens.parent does not exist (SQLSTATE 42703)

and

AuthApiError: error finding refresh token: ERROR: column refresh_tokens.parent does not exist (SQLSTATE 42703)

Can anyone let me know how I resolve these issues?

Thanks

[silentworks]

You need to open a new discussion on here and also share some code. It's hard for anyone to say what's going wrong without any code to look at. Ping me when you open a new discussion on here and I'll take a look at it.

[wiwa]

The code is in the link, I believe in (root) +layout.ts. As we can see, there is no setAll() method defined, as the (@supabase/ssr) warning says. So is this expected (i.e. the warning is wrong), or are the docs incorrect?

  const supabase = isBrowser()
    ? createBrowserClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
        global: {
          fetch,
        },
      })
    : createServerClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
        global: {
          fetch,
        },
        cookies: {
          getAll() {
            return data.cookies
          },
        },
      })

[kvetoslavnovak]

Sharing my implementation in SvelteKit, This setup mainly seems to solve the infamous user object warning logs. Also uses locals to store/pass the session and user which I consider more secure (see). This example also proposes a way to delete Supabase SSR cookie when the user account was deleted directly in the database but the session is still in his browser.

Feedback from @hf would be very welcomed.

EDIT: After testing I can onfnirm that auth.updateUser still caused the infamous warning logs :-(

Here is my full SvelteKit tutorial if anyone is interested.

// hooks.server.js
import { PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY } from '$env/static/public'
import { createServerClient } from '@supabase/ssr'

export const handle = async ({ event, resolve }) => {
  event.locals.supabaseServerClient = createServerClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
      cookies: {
          getAll() {
              return event.cookies.getAll()
          },
          setAll(cookiesToSet) {
              cookiesToSet.forEach(({ name, value, options }) =>
                  event.cookies.set(name, value, { ...options,path: '/' })
              )
          },
      },
  })


  const getSessionAndUser = async () => {
      const { data: { session } } = await event.locals.supabaseServerClient.auth.getSession()
      if (!session) {
          return {
              session: null,
              user: null
          }
      }

      const { data: { user }, error } = await event.locals.supabaseServerClient.auth.getUser()
      if (error) {
          // JWT validation has failed
          return {
              session: null,
              user: null
          }
      }

      delete session.user
      const sessionWithUserFromUser = { ...session, user: {...user} }

      return { session: sessionWithUserFromUser, user }
  }

  const { session, user } = await getSessionAndUser()

  event.locals.session = session
  event.locals.user = user

  return resolve(event, {
      filterSerializedResponseHeaders(name) {
          return name === 'content-range' || name === 'x-supabase-api-version'
      },
  })
}

// +layout.server.js
export const load = async (event) => {
// covering the case when the user was deleted from the database, the cookie needs to be deleted in the browser
  if (event.locals.session == null) {
  event.cookies.delete(event.locals.supabaseServerClient.storageKey, { path: '/' });
}

  return {
      session: event.locals.session,
      user: event.locals.user
  };
};

// +layout.js
import { PUBLIC_SUPABASE_ANON_KEY, PUBLIC_SUPABASE_URL } from '$env/static/public'
import { createBrowserClient, createServerClient, isBrowser } from '@supabase/ssr'

export const load = async ({ fetch, data, depends }) => {
  depends('supabase:auth')

  const supabase = isBrowser()
    ? createBrowserClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
        global: {
          fetch,
        },
      })
    : createServerClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
        global: {
          fetch,
        },
        cookies: {
          getAll() {
            return data.cookies
          },
        },
      })

      const session = isBrowser()
      ? (await supabase.auth.getSession()).data.session 
      : data.session

  return {
    supabase,
    session,
    user: data.user
  }
}

[itsmikesharescode]

this much simplier

[kvetoslavnovak]

It is just about the coding style and personal preferences I guess. I was always thought functional programming and name functions properly,
So for me getSessionAndUser returning session and user seems clear. safeGetSession not so much, especially if we use it to get not only the session but the user as well. Also in my app I need to have separate locals for user and for the session vs one returnig both.

[C4T4]

Please improve the DX for getUser and getSession in Next.js. It’s confusing to know when to use each.

Clear guidelines and examples would help.

[wong2]

I'm also in this predicament; it seems like getSession isn't safe, but getUser means more queries from my server to the Supabase database.

[BorisBarzotto]

This would be the implementation for NextJS 14?

import { cookies } from 'next/headers';
import { type CookieOptions, createServerClient } from '@supabase/ssr';

const cookieStore = cookies();

    const supabase = createServerClient(
      process.env.NEXT_PUBLIC_SUPABASE_URL!,
      process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
      {
        cookies: {
          getAll: () => {
            return cookieStore.getAll()
          },
          setAll: (cookiesToSet: { name: string; value: string; options: CookieOptions; }[]) => {
            cookiesToSet.forEach(({ name, value, options }) => {
              cookieStore.set({ name, value, ...options });
            });
          }
        },
      }
    )

[jeromevvb]

In my case, Supabase set duplicate auth cookies; the old ones are not being removed/rewritten when the session is refreshed. This causes an indefinite call to the endpoint token?grant_type=refresh
I have opened a discussion here and might need to do something differently. Any help would be appreciated 🙏🏻
https://github.com/orgs/supabase/discussions/29997

[serhii-kucherenko]

In my case it's the size of cookie

[om154]

@hf just wanted to follow up on this thread, any further updates on v1.0.0 release timeline?

[dalkommatt]

https://x.com/stojaaan/status/1863880328214982720

[eurlexa]

Are there any news?