fix: suppress getSession warning whenever _saveSession is called

[kangmingtay]

What kind of change does this PR introduce?

• we can safely suppress the warning returned by _getSession whenever _saveSession is called
• this further reduces the noise in Can't get rid of getUser() warning #873

[dagassa]

🙏

[larbish]

Hey @kangmingtay, maintainer of the nuxt/supabase module here.

We have a PR to migrate on the @supabase/ssr package and we're still experiencing this issue with the latest released version.

I've removed all occurrences of getSession() in the module and I still have the warning.

Any help on this would be appreciate 🙏 I can't merge and release this PR until I get rid of this warning.

[ekendra-nz]

Still get :

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.

with

		"@supabase/supabase-js": "^2.44.4",
		"@supabase/ssr": "^0.4.1"
		

[AdrienLF]

Same here with

		"@supabase/ssr": "^0.4.0",
		"@supabase/supabase-js": "^2.45.0"

[marcusklausen]

Any reason there's not just a prop we can pass to getSession() to suppress the warning manually? This safeguarding is very overboard I think. It is already perfectly clear that getSession is not safe for authorization on it's own.

I think it's a very common thing to use getSession in nextjs middleware. Having to do a roundtrip to supabase servers using getUser on each request on an edge network is just bonkers, so getSession makes sense for the routing. And using getSession in middleware causes an unbelievable amount of warnings in the log, to the point where debugging other stuff becomes really cumbersome.

[greendra8]

I've gone banner blind to this log I've seen it so much. Please fix!

[outranker]

annoying af

[jeromevvb]

Can you please explain in what sense this warming makes sense?
I am using Next JS, and on the middleware, I have a getUser (await supabase.auth.getUser()) check for my protected route (which is slow, by the way)

Since I have the user checked on my middleware, why would I want to get the user again? i would likely use getSession

[marcusklausen]

@jeromevvb you would likely do it the other way around, route access based on getSession but verify the user against supabase before fetching any data or running server actions etc. The latter would not be secure if you use getSession in those and calling getUser in the middleware causes excessive requests to third party making every request matched by the middleware super slow for no reason at all in most cases.

Nevertheless I've tried to make a PR for suppressing the warning but I'm not sure how I can get someone to look at it.
#953

[jeromevvb]

@marcusklausen Thank you for your answer!
However, I thought the reason Supabase is calling getUser in the middleware is to refresh the token if needed. How do you handle this?

[marcusklausen]

@jeromevvb well any time data is fetched in a server component or the user triggers a server action, if you use getUser in those cases, you're achieving the same. But having it in the middleware means it'll trigger on loads of requests, even images etc, if the matcher is not setup correctly. It makes 0 sense to me.

[jeromevvb]

Hey @marcusklausen
Thank you so much for your insights.
My application is mainly on the client side; therefore, if you use getUser in the client component, would this also refresh the token? Do I need to add "cookies" in the create client for the client-side?
Thank you!

[marcusklausen]

@jeromevvb if you want to authorise the user client side you have to use getUser as you have no other way for validating their credentials than to make the roundtrip to sb servers and verify. You dont need cookies for that.

The token is not refreshed though