Replies: 23 comments 120 replies
-
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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
I'm seeing it as a major improvement to have it in its own repo as well as removing the rather redundant However, having seen struggling users with the existing ssr package just a little bit, I felt that 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:
|
Beta Was this translation helpful? Give feedback.
-
I wonder if it would be better to rewrite Just spit balling. J |
Beta Was this translation helpful? Give feedback.
-
Thanks for the update. My team and I have been working on migrating to Overall, would you suggest migrating from |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
-
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: I will update and link to the new docs for each framework soon. |
Beta Was this translation helpful? Give feedback.
-
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:
However the issue is that I can't update this header after the client is created so if the 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
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 :) |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Any update on this?? This give me an extreme anoyance |
Beta Was this translation helpful? Give feedback.
-
I took RC5 to migrate and didn't change the
The interesting part is that it is NOT used in a server-environment but in a NextJS 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: |
Beta Was this translation helpful? Give feedback.
-
Version 0.4.0 is published! Who needs to upgrade:
Example guides have been updated: 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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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),
)
},
},
},
)
} |
Beta Was this translation helpful? Give feedback.
-
what now should i abort using ssr for now and find diff solutions? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Using SvelteKit I still get an error, and I cant even get my app to open in the browser: It appears 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? |
Beta Was this translation helpful? Give feedback.
-
I'm eagerly awaiting the sveltekit docs to land and confirmation it is working and makes sense! |
Beta Was this translation helpful? Give feedback.
-
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:
and
Can anyone let me know how I resolve these issues? Thanks |
Beta Was this translation helpful? Give feedback.
-
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 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
}
} |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
This would be the implementation for NextJS 14?
|
Beta Was this translation helpful? Give feedback.
-
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
.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
andremove
like so:You would need to define two —
getAll
andsetAll
cookie access methods like so:Note that for
createBrowserClient
nothing needs to be done in most cases, it automatically works with thedocument.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!
Beta Was this translation helpful? Give feedback.
All reactions