getClaims() is not in Framework documentation

[jdgamble555]

Documentation is

• Missing
• Outdated
• Confusing
• Not sure?

Explain in Detail

All of the Server Framework Documentation still uses getUser() by default, which means there is an extraneous call to the database. Supabase created getClaims() for this purpose increasing the speed and security of Supabase Auth.

The docs should reflect this by default.

Outdated Setup

• NextJS - see middleware.ts
• SvelteKit - see hooks.server.ts

No Server Setup At All

• Nuxt - this doesn't even have a server endpoint setup and is just a Vue setup
• SolidJS - There should be a SolidStart version for server

The @supabase/ssr makes it easy to add functionality to any framework, and could easily be used in place of outdated addons like:

• Qwik Supabase
• Nuxt Supabase

I am happy to help create a demo for all of these if necessary (just let me know), but first SvelteKit and NextJS docs need to be updated with getClaims() instead of getUser(), and before getClaims() can be useful, the typing problem should be fixed.

J

Your Suggestion for Changes

No response

Documentation URL

No response

Steps to reproduce

No response

[mandarini]

Thanks for creating this issue @jdgamble555 ! I will look into this soon. Once I create the PR, I will ping you if I need any help adding a demo!

[j4w8n]

The docs are lagging at this point, but I've been hesitant to do anything because they've been working on an overhaul:

supabase/supabase#38405

I don't think the above PR is so much about updating the framework code but rather reorganizing how Supabase does the page layout or whatever. Still, you might verify with them.

I've seen some talk of SvelteKit remote functions as well, but I think that needs to wait until it's no longer under an experimental flag.

[ChrisChinchilla]

Hey @jdgamble555, so some of this was addressed with a PR earlier today. For the SSR section specifically, I have another long-running PR that made a lot of changes to the SSR content, including the methods used. That is just waiting for a final review, and most of what you brought up should be addressed.

Then there is one outstanding task to update https://github.com/supabase/supabase/blob/f1ca06f2ea022ae8bb2ae45db2dcb043345a8139/apps/docs/content/guides/getting-started/tutorials/with-nextjs.mdx as it requires more thought and work, help there is appreciated.

I also want to create additional guidance throughout the Auth section, explaining the differences between getUser and getClaims, as it's not always clear. However, these two PRs should address a significant portion of your concerns.

[jdgamble555]

Nothing can be updated correctly until getClains() typing is fixed.

I am happy to help with NextJS and SvelteKit examples once this is done.

[mandarini]

@jdgamble555 @ChrisChinchilla this (#1802) has now been merged, so we can move on with the docs.

[jdgamble555]

https://supabase.com/docs/guides/getting-started/tutorials/with-sveltekit

Updating the above example to use getClaims(), here is my repo:

https://github.com/jdgamble555/sveltekit-supabase-demo

I would never build what they did, and I think it could be simplified and have cleaner code, but it is the example already provided. I can modify the NextJS example as well, or I can create something new.

I would suggest creating a basic "User Management" example that works and looks exactly the same across different frameworks.

I would also suggest getting rid of this page entirely (different from one above):

https://supabase.com/docs/guides/auth/server-side/sveltekit

And consolidating the Frameworks to Server Side and Client Frameworks:

SSR

• SvelteKit
• NextJS
• Remix
• Qwik
• etc

Client

• Angular
• Svelte
• React
• etc

Let me know how you want me to handle this, as I don't mind building a cleaner example. Also, not sure if I needed to do PR once the examples are approved.

J

[mandarini]

Thank you for your contribution @jdgamble555 ! I will work with @ChrisChinchilla to get these docs updated. We will let you know if a PR is needed.

[j4w8n]

Personally, I'd be in favor of dropping the "Safe" verbiage going forward.

[jdgamble555]

Do you want me to build a better and cleaner example that is the same across frameworks?

Let me know what this should look like...

J

[jdgamble555]

@ChrisChinchilla - I'm also assuming you should still use getUser() for more secure tasks like update password etc? How should this be handled...

J

[mandarini]

@jdgamble555 @j4w8n we are discussing this internally, and will report back. Thank you for bearing with us. Thank you for contributing. In any case, updates will go here.