auth-js
auth-js copied to clipboard
supabase
Can't get rid of getUser() warning
Bug report
I keep getting the getSession() error about 500 times on one page.
Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.
- [x] I confirm this is a bug with Supabase, not with my own application.
- [ ] I confirm I have searched the Docs, GitHub Discussions, and Discord.
Describe the bug
This warning should not exist. I do not want to contact supabase on my non-logged in pages to see if a user is logged in. That would be two round trips, which would slow down my app. There is nothing wrong with checking for a session cookie on my server without doing an extra request. Either way, I am following the tutorials exactly.
To Reproduce
Follow any one of the tutorials:
https://supabase.com/docs/guides/auth/server-side/creating-a-client
Expected behavior
Do not show the warning at all, or allow me to disable warnings. At the very least, do not show it 500 times on one page.
Screenshots
If applicable, add screenshots to help explain your problem.
System information
- supabase - 1.151.1
- @supabase/ssr - 0.1.0
- @supabase/supabase-js - 2.41.1
Additional context
It is an issue with this line of code
Please see the linked repository: https://github.com/supabase/auth-helpers/issues/755
J
I have the same issue after running a rm -rf node_modules and reinstalling for sveltekit SSR. (Could also be reinstall independent. I immediately went for a reinstall this morning so i don't know if these logs were printed before reinstall).
I've followed the SSR guide exactly and even on the home page load this error shows up on first load.
VITE v5.2.7 ready in 499 ms
➜ Local: http://localhost:5173/
➜ Network: http://192.168.50.35:5173/
➜ Network: http://10.0.0.1:5173/
➜ press h + enter to show help
Using supabase.auth.getSession() is potentially insecure as it loads data directly from the storage medium (typically cookies) which may not be authentic. Prefer using supabase.auth.getUser() instead. To suppress this warning call supabase.auth.getUser() before you call supabase.auth.getSession().
Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.
Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.
Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.
Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.
Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.
This is on home page load, without any user being authenticated.
Also encountering this. I just want to have a simple and fast route guard and only want to call getUser when necessary. Calling getUser is currently adding around 1800-2000ms latency to all of my routes.
Wondering if this may be the reason I'm having very high number of auth API calls
I'm getting this issue even though I don't have a call to getSession() in my codebase lol
Something in SupabaseClient seems to call it, fetchWithAuth calling _getAccessToken potentially.
So even something as innocuous as this seems to throw it.
import StaffWithRoleType from '@/app/types/database/staff-with-role.type';
import { createClient } from '@/app/utils/supabase/server';
const fetchStaff = async () => {
const supabase = createClient();
const { data: staff, error } = await supabase
.from('staff')
.returns<StaffWithRoleType[]>();
...
https://github.com/supabase/auth-js/blob/92fefbd49f25e20793ca74d5b83142a1bb805a18/src/GoTrueClient.ts#L936
Oh nice a fresh issue 👁️👄👁️
Same here, all I do is the basic @supabase/ssr setup, never call getSession in my code. Thank you.
I found the source code that throws this warning, in the case where you don't explicitly call getSession() in your own code. It's in supabase-js, and calls getSession() when you use a supabase client on the server-side.
So, code like const { data, error } = await supabase.from('table').select('*') will throw the warning, because of https://github.com/supabase/supabase-js/blob/master/src/SupabaseClient.ts#L103, which executes _getAccessToken(), which calls getSession() https://github.com/supabase/supabase-js/blob/master/src/SupabaseClient.ts#L243L247
This is a mess, why would they put a crazy mandatory warning like this without running proper tests.
We need to be able to check for a session on our server without calling a function to supabase server. If there is a session, then we verify by doing the extra call to the supabase server. We should not be mandated to verify a session for non-logged in users.
J
This is a mess, why would they put a crazy mandatory warning like this without running proper tests.
We need to be able to check for a session on our server without calling a function to supabase server. If there is a session, then we verify by doing the extra call to the supabase server. We should not be mandated to verify a session for non-logged in users.
J
yeah, here are the two relevant PRs: https://github.com/supabase/auth-js/pull/846 https://github.com/supabase/auth-helpers/pull/722
looks like the fix is not ready: https://github.com/supabase/auth-js/pull/874
looks like the fix is not ready: #874
It looks like that fix does one thing: only turns off the warning if there's no error from the getUser() call, ie there's a user logged-in. This is because calling getUser() when no one is logged in will return an invalid claim: missing sub claim error, but still passes back result.data -> { user: null}. So they're making sure they don't turn off the warning unless there's a valid user logged in.
After pondering that PR a bit more, it's actually going to make things worse; even though it's the better code choice from a security perspective. https://github.com/supabase/auth-js/pull/874#issuecomment-2040640456
Same here, issue arises from gotrue client
This is so annoying, logs warnings even when I use getSession() in my middleware
Please fix the issue or at least make it non recursive. We can read warnings once not 1000+ times. I prefer my console tidy this is a mess
I am just playing around with the Stripe supabase template, and this is the hack I did to suppress that warning message for now. Not ideal, for sure, but makes the dev terminal a lot quieter :)
Before returning the client, I just call client.auth.getUser()
