SSR server requests at the same time not updating user metadata
I am using supabase with nextJS, and attempting to refresh a provider token (in this case, github for us) when the provider token expires. I am storing the provider token in the
I am getting supabase c/p from the docs (photo attached)
Ex error: I get 4 simultaneous server requests that require a provider token. Since the provider token for those will all be expired given the token for a given user has the same expiration date, I've created a server lock system that attempts the refresh on one of those requests, while the others wait and poll to see if a new provider token is on the user.
I see that the refresh succeeds
Then I release, the lock, which allows the rest of the 3 requests to check for the new user.
However, the user returned has the old provider token.
My suspicion is it's not actually going to the server to grab the user, becuase i see this warning in the logs at this time, but i'm not calling
Or is it because getUser is server, but updateUser shouldn't be used here? Should I be storing the token in a DB instead?
user.user_metadata that supabase returns from getUser(). The issue is, following the docs, I am not getting the updated user metadata when calling await supabase.auth.getUser(); after a successful refresh of a token, and re-storking it with updateUser. More details below:I am getting supabase c/p from the docs (photo attached)
Ex error: I get 4 simultaneous server requests that require a provider token. Since the provider token for those will all be expired given the token for a given user has the same expiration date, I've created a server lock system that attempts the refresh on one of those requests, while the others wait and poll to see if a new provider token is on the user.
I see that the refresh succeeds
Successfully refreshed provider token for user:, band store the new provider token in await supabase.auth.updateUser in the attached image.Then I release, the lock, which allows the rest of the 3 requests to check for the new user.
However, the user returned has the old provider token.
My suspicion is it's not actually going to the server to grab the user, becuase i see this warning in the logs at this time, but i'm not calling
getSessionUsing 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 may not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server. Or is it because getUser is server, but updateUser shouldn't be used here? Should I be storing the token in a DB instead?
