@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.

[hf]

Could you provide an example of what you would ideally need?

[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!

[silentworks]

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

[codewithjohnson]

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?

[hf]

Migrate today! We are not too far out from v1.0.0 -- waiting on some tech changes to happen inside Supabase so we can roll out an even better DX. Once that's done, v1.0.0 is going to become a reality.

auth-helpers-x have more issues than v0 of ssr!

[om154]

Great! Thanks for the insight

[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?

[j4w8n]

@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.

[j4w8n]

@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

[j4w8n]

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.

[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.

[hf]

Oops, must have slipped up. On it!

[morgler]

don't know if this is the right place, but I had to make the following changes due to errors in nextjs:

In middleware.ts I had to

• provide an absolute url instead of a relative one (by cloning the existing one and changing the pathname)
• prevent it from recursively redirecting on the login form (this could be only my issue though)

  if (!user && !request.nextUrl.pathname.startsWith('/auth')) {
    // no user, potentially respond by redirecting the user to the login page
    const url = request.nextUrl.clone()
    url.pathname = '/auth/login'
    return NextResponse.redirect(url)
  }

On another note:

The middleware in the web app demo tutorial is also still using the old getand setmethods (https://supabase.com/docs/guides/getting-started/tutorials/with-nextjs#supabase-server-side-auth)

[activenode]

provide an absolute url instead of a relative one (by cloning the existing one and changing the pathname)

That has pretty much always been the case and is nextjs related, not at all has anything to do with Supabase.

prevent it from recursively redirecting on the login form (this could be only my issue though)

Yeah sounds like a mismatch of cookies really. i've experienced this so I know what you mean: You check for login: redirect, login succeeds, session is refreshed, goes back to login, same game starts.

This is due to a misconfiguration somewhere. Please follow the EXACT docs to check what happens. So get rid of ANY custom middleware stuff first to check this. It should then NOT happen. then re-add your custom stuff one by one and see where the issue is.

[itsmikesharescode]

when the sveltekit guide be updated

[thenbe]

I believe there are some updated sveltekit docs here: https://github.com/supabase/supabase/blob/master/apps/docs/content/guides/auth/server-side/creating-a-client.mdx

But the full "Server-Side Auth for SvelteKit" guide is yet to be updated: https://github.com/supabase/supabase/blob/master/apps/docs/content/guides/auth/server-side/sveltekit.mdx

[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

[activenode]

Not sure if I got your question right but: You cannot get notified about a TOKEN_REFRESHED in the browser if the token is refreshed in the middleware. Same as you can't delete an entry in the database in the frontend if it was already deleted on the server.

Might've misunderstood you?

[atsakiridis]

It’s not intuitive what happens under the hood of the Supabase SDK, and whether the client is somehow synced internally with the server for convenience. The migration guide wasn’t clear in this respect either. So we expected similar DX as previously, where you would use a Supabase provider + relevant onAuthStateChange() events as a central way to keep auth state cached on the client side and shared between components. That also made usage in client components easier, as we didn’t have to deal with Effects when using supabase.auth.get()*

Do you suggest that onAuthStateChange() is no longer applicable with supabase ssr package?

[activenode]

Hm, it never was quite honestly. It depended on the flow which you were using. It is applicable on the server-side as well as on the client side.

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.

So I understand it being slightly confusing, can relate but just trying to clarify that there never was a "server and client" thing where they synced. Either you authenticated on the client and got the authStateChange there, or you did it on the server. It might've felt different to some extent

[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?

[j4w8n]

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?

[j4w8n]

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

[j4w8n]

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

[stevengrimaldo]

for reference i had several utility query functions, similar to this model, where i am importing createClient from the utils/supabase/server.ts file as seen in the setup docs - rather than passing the client from the page to the utility but worked just fine until now.

Example query util:

import { cache } from 'react';
import { createClient } from '@/utils/supabase/server';

export const getPlaylistByID = cache(async (id: Playlists['Row']['id']) => {
  const supabase = createClient();

  const { data, error } = await supabase
    .from('fe_playlists')
    .select('*, scenes:fe_join_scenes_playlists(*, scene:fe_scenes(*, type:fe_scene_types(*)))')
    .eq('id', id);

  return { data, error };
});

In use i would import that util into a page.ts file in the app router and pass the data down via props after.

[ham-evans]

Check if you're importing the Supabase Server createClient in a client component (has "use client" at the top) instead of importing the Supabase client createClient

[stevengrimaldo]

Check if you're importing the Supabase Server createClient in a client component (has "use client" at the top) instead of importing the Supabase client createClient

definitely ill check right now but was working just fine before making the upgrade to 0.4.0 which is what i found interesting.

[stevengrimaldo]

Check if you're importing the Supabase Server createClient in a client component (has "use client" at the top) instead of importing the Supabase client createClient

definitely ill check right now but was working just fine before making the upgrade to 0.4.0 which is what i found interesting.

i checked and didnt find any on pages or files with 'use client', although after visiting a different page then back to the page i had an issue on im no longer seeing the issue interestingly enough, so all is good so far.

[ham-evans]

On v0.4.0 migration (from auth-helpers-next) I started getting these warnings (errors?) during build only. Still builds no problem and I know how to fix but super unhelpful as no clue where its happening. Seeing over 20 of the same error...

Error: Functions cannot be passed directly to Client Components unless you explicitly expose it by marking it with "use server". Or maybe you meant to call this function rather than return it.
  {}
    at ek (/vercel/path0/node_modules/.pnpm/next@14.2.4_@babel+core@7.24.5_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:140735)
    at ek (/vercel/path0/node_modules/.pnpm/next@14.2.4_@babel+core@7.24.5_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:138213)
    at eP (/vercel/path0/node_modules/.pnpm/next@14.2.4_@babel+core@7.24.5_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:142124)
    at eE (/vercel/path0/node_modules/.pnpm/next@14.2.4_@babel+core@7.24.5_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:142698)
    at Timeout._onTimeout (/vercel/path0/node_modules/.pnpm/next@14.2.4_@babel+core@7.24.5_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:135475)
    at listOnTimeout (node:internal/timers:573:17)
    at process.processTimers (node:internal/timers:514:7) {
  digest: '639124533'

[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)

[j4w8n]

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.

[j4w8n]

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!

[itsmikesharescode]

Same i find nextjs as priority. But its ok

[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.

[j4w8n]

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.