Supabase Auth hitting rate limit 429 too often in development
I have a small NextJS app. It's my understanding we should be calling the helper
createServerClient in server components to authenticate requests (to do some db stuff). I am doing so in a few pages and server actions, but I often find myself hitting 429. Is this really how it's supposed to work? How will my app survive in production if a few clicks here and there causes this? Let me know, in general terms, what I should look out for. I'm pretty experienced with NextJS and web dev as a whole, but perhaps am missing something specifically about Supabase Auth. Thanks in advance.16 Replies
In general creating a client does not make any calls to the supabase server. Can you see in the dashboard api edge logs what calls are coming in? https://supabase.com/docs/guides/platform/going-into-prod shows the limits on endpoints. Something seems to be going wrong with needing to refresh tokens when that should not be required with auth-helpers until they get close to expiring.
I had another user though reporting similar things either yesterday or day before. Unfortunately I don't know the inner workings of auth-helpers and in particular SSR. You don't mention which is involved.
So yes something is amiss and should not be happening. Whether is your code or a bug I think remains to be seen.
I'm particularly suspicious of getUser() which normally should not be used versus getSession().
Production Checklist | Supabase Docs
Things to do before making your app publicly available
I'm seeing this on 1 page. I refreshed it and these requests showed up. Is this indicative of something wrong?
I do use getUser more often. I think this is the issue. Get session would rely on the token in localStorage instead of a round trip..
Thank you @garyaustin
If swapping over to session doesn't help, I'll be back with more details.
You always want to use getSession() unless you know you need to get the very latest JWT from the server.
Wouldn't you need to get the latest on requests that show protected stuff though?
Also..
From the NextJS starter:
Seemingly, they use getUser in most places
Actually.. this makes sense to me now. This is the whole point of a JWT.
Never mind and thank you again.
Yeah, I'm nervous about this, because I'm surprised it would cause an issue if the guides recommend it. But getUser is very wasteful unless you are modifying the auth.user table with a new app_metadata value or something.
I guess there should be better documentation around it
but what you said about getSession makes sense to me. It's the same as rolling your own JWT and verifying the token instead making a db call..
The second bullet point is somewhat misleading.
Ha, but the 3rd is not...
yes!
thank you for your time. How do I close this ticket?
Just tag it with solved. There are no "tickets" here as this is mainly user helping user forum.
@garyaustin Hmmm. just replaced project-wide with getSession. Still about 30 reqs per page load. Clicking around and doing some basic db operations (which all call getSession before) gets me 429 still.
I don't know something seems wrong. You should see the requests in API Edge log or Auth logs in the dashboard. Most limits seem to be hour based.
Are you using SSR or the "old" auth-helpers?
OK if getSession is calling the API 30 times, then somewhere your cookies are not passing the correct info. My guess is the offending client making the calls is thinking the session is expired so even getSession will call the server to refresh the token. Have you changed your jwt expire time in the dashboard?
I
rm -rf node_modules, reinstalled. Quit Chrome, re-opened. and now everything's all good. No extra reqs on getSession. Only seeing /login and /logout in the Auth logs.
Perhaps this was an issue with NextJS's hot module reloading.
Working as expected.