Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

user object warning logged, even when not touching session.user #888

Open
2 tasks done
j4w8n opened this issue Apr 24, 2024 · 13 comments
Open
2 tasks done

user object warning logged, even when not touching session.user #888

j4w8n opened this issue Apr 24, 2024 · 13 comments
Labels
bug Something isn't working

Comments

@j4w8n
Copy link
Contributor

j4w8n commented Apr 24, 2024

Bug report

  • 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

With [email protected] and the ssr auth helper package, after a user logs in, the below warning is logged to the server console five times, with a fairly minimal SvelteKit app. This happens despite the fact that none of my code is calling session.user, nor am I destructuring the user property from session, or destructuring with ...rest-type syntax.

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.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

https://github.com/j4w8n/getsession-warning

Expected behavior

The warning should not log when dev code doesn't explicitly call session.user.

Root Cause

I figured out why the first three logs happen: the Supabase client's server-side storage, from +layout.ts, is returning stringified JSON. You can see this in the docs. JSON.stringify() causes each property of session to be touched during the stringify process, which inevitably calls session.user. So, each time _useSession() is called, whether implicitly through dev code like getSession() or explicitly with internal auth-js processes, the warning is being logged.

I can't figure out where the final two warning logs are coming from. Could be from the same client initialization as above, but perhaps whatever triggers it is getting run asynchronously, so it's logging later.

Even if this warning wasn't an issue in the context of ssr, it could still be problematic, as the auth-js client itself calls session.user when updating a user, setting a session, refreshing a session, and more - at least some of which could theoretically happen server-side.

System information

  • OS: Windows, with or without WSL.
  • Browser N/A
  • Version of supabase-js: 2.42.5
  • Version of ssr: 0.3.0, but it should happen on earlier versions too I'd think.
  • Version of Node.js: N/A

Additional context

#873
#873 (comment)
https://tc39.es/ecma262/multipage/structured-data.html#sec-json.stringify
https://tc39.es/ecma262/multipage/structured-data.html#sec-serializejsonproperty
https://github.com/supabase/auth-js/blob/master/src/GoTrueClient.ts#L1111-L1124

@j4w8n
Copy link
Contributor Author

j4w8n commented Apr 27, 2024

@j4w8n
Copy link
Contributor Author

j4w8n commented Apr 28, 2024

It's likely the other two warnings, that I couldn't figure out how they are triggering, are triggered when SvelteKit checks if passed values are POJOs, in certain situations. See #873 (comment)

@kangmingtay
Copy link
Member

hey @j4w8n, we made another attempt in this PR to further cut down on the repeated warning logs returned - basically everytime we detect that a new session is saved, we set a flag to suppress the warning internally

@j4w8n
Copy link
Contributor Author

j4w8n commented May 2, 2024

Thanks @kangmingtay. I suspect that PR will resolve issues for some people - specifically the ones exclusively experiencing this when calling things like updateUser(). However, this has basically no effect for SvelteKit users - at least not on initial login and hard refreshes - because of the nature of what I explained in the first paragraph of the Root Cause section.

As an aside, how do I test an RC? I added an override in my package.json, and after doing bun install it claimed it installed one thing. When I go to the auth-js package.json the version is 2.64.2-rc.1, but none of the code from the release is in there - I had to add it manually to test. I was looking in dist/main/GoTrueClient.js, but I even glanced at the .ts version in src and saw nothing. I had this experience with pnpm as well, in another demo app.

@j4w8n
Copy link
Contributor Author

j4w8n commented May 2, 2024

@kangmingtay looks like there is something wrong with the build process for RCs. If you checkout the code on npm, you'll see the PR code is not there.
https://www.npmjs.com/package/@supabase/auth-js/v/2.64.2-rc.1?activeTab=code

@kangmingtay
Copy link
Member

@j4w8n ah good point, not sure why the release workflow got skipped in the first attempt but i reran it and it's published to npm so you should be able to test it out

@kangmingtay
Copy link
Member

@j4w8n yeah your analysis is right, any method that implicitly accesses the user property in the session object will trigger the warning log.

i think we can implement your suggestion here so the warning is only logged once per proxy session, but will need some time to test this out since we're currently quite tight on bandwidth

@vehm
Copy link

vehm commented May 3, 2024

Confirming that we are continuing to receive the warning in SvelteKit after #895 as mentioned here.

Will follow.

@j4w8n
Copy link
Contributor Author

j4w8n commented May 3, 2024

Until this issue is resolved, and perhaps even after that, I've tweaked my demo app - v0.3.0 - to where I no longer receive any warnings.

My solution is done in a legitimate way, which checks all of the security boxes. The code in hooks.server.ts verifies the JWT and uses it's decoded data to craft a validated session. This session will pass any internal auth-js checks, as well as type checks.

https://github.com/j4w8n/sveltekit-supabase-ssr

@silentworks
Copy link
Contributor

I think the suggestion here from @j4w8n is great but I'd also like a way to suppress this warning completely in production build. I don't want this to be logging inside of my application terminal when its being run in production mode.

kangmingtay pushed a commit that referenced this issue May 9, 2024
## What kind of change does this PR introduce?

Bug fix.

## What is the current behavior?

A call to `getSession()`, when using server storage, logs a warning
every time `session.user` is accessed. This is causing a lot of people
to see multiple consecutive logs to the console - especially for
SvelteKit users.

## What is the new behavior?

Ensures that accessing `session.user`, from a `getSession()` call, only
logs the warning once per Proxy session instance. In other words, once
per server request.

## Additional context

#888
@itsmikesharescode
Copy link

any update?

scosman added a commit to CriticalMoments/CMSaasStarter that referenced this issue May 22, 2024
scosman added a commit to CriticalMoments/CMSaasStarter that referenced this issue May 22, 2024
* Sveltekit 2 migration!

Mostly just running `npx svelte-migrate@latest sveltekit-2` and fixing package conflicts.

Use @supabase/auth-helpers-sveltekit to ^0.11 to avoid supabase/auth-js#888
@Salman2301
Copy link

Still logging, try different way to suppress it too, seems nothing works vite, sveltekit onwarn .... Svelte should somehow allow us to suppress certain log. Just incase if any of the lib are abusing it.

@itsmikesharescode
Copy link

any update??

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants