using @supabase/ssr clients with nextjs

[LORE-D-NATO]

I'm currently going through the server-side auth guide for Next.js, and was hoping someone could help me understand something. When mutating data from a client component, what is the difference between using the ssr package's createBrowserClient and calling a server action that uses createServerClient? When should I be using each?

[charislam]

Depends on whether you want to run the code on the client or server! (Pretty much the same question you have with any event handler in Next.js App Router.)

If you're doing something like a realtime subscription to track cursor positions on some kind of collaboration app, that's a pretty clear use case for running the code on the client.

If you're making a request for data and you need to do a lot of data manipulation to get it in a renderable form, that's possibly an argument for running the code on the server.

Then there are a lot of in-between cases, it depends on exactly what you're trying to do and what performance trade-offs you need to make. (Client code runs on the user's browser and can lead to janky interactions if it hogs the main thread, but there's no network time, aside from the time needed to call Supabase. Server code runs on the server so less JS shipped to the client and less work in the browser, but you have to account for the extra network hop to the server.)

[LORE-D-NATO]

Got it, thank you! Are there any security considerations I should take note of when deciding which to use?

[charislam]

Some general things I can think of off the top of my head:

• Thinking about whether you need to access any server-side secrets. The Supabase anon key is safe to use in the browser when paired with RLS, but you might need other secrets (for example, an OpenAI or other third-party API key), and only the server will keep them safe.
• Being careful about validating the user on the server side. Nothing on the client is tamper-proof (a user can always edit their own local storage, cookies, variables, or fetch request bodies, for example), but we often assume the server is tamper-proof, which is only true if you validate incoming requests. So, for example, if you need to know if a request is coming from a logged-in user, you should always call supabase.auth.getUser(). You should never use supabase.auth.getSession() on the server, because that isn't guaranteed to validate the received Auth cookie. (It checks for its existence and its expiry, and if it isn't expired, it returns the cookie data as it was sent, without checking that the cookie was properly signed by the Auth server.) We have warnings in the docs about this.

[denisfilab]

I wanted to confirm: Is it safe to use supabase.auth.getSession() for logging in with the Supabase client, or should we always use supabase.auth.getUser() for validating the user when the login/signup was used with createBrowserClient?