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

onAuthStateChange should fire on initial load #326

Closed
mikob opened this issue Oct 13, 2021 · 8 comments
Closed

onAuthStateChange should fire on initial load #326

mikob opened this issue Oct 13, 2021 · 8 comments
Labels
auth enhancement New feature or request help wanted Extra attention is needed

Comments

@mikob
Copy link

mikob commented Oct 13, 2021

Feature request

Is your feature request related to a problem? Please describe.

Currently it seems there is no deterministic way to know if a supabase session is done with initial loading.

If the user is signed out,auth.session() will return null and onAuthStateChange won't fire. If the user is signed-in, auth.session() will return null, but then onAuthStateChange will fire soon after with the session data.

Consider this code:

        const sess = supabase.auth.session();
        log("session event", sess);

        changeSession(sess);

        supabase.auth.onAuthStateChange((_event, session) => {
            log("session event", _event);
            changeSession(session);
        });

A clear and concise description of what you want and what your use case is.

I need to load certain user history with knowledge of whether the user is signed-in or not. Yes it's possible to first fire assuming they aren't logged in, and then backtracking and firing again (once onAuthStateChange is hit) saying actually they are signed in, but it forces me to fire changeSession a function which is resource intensive on my end twice.

Describe the solution you'd like

Either onAuthStateChange should fire initially by default (how firebase auth works BTW), whether the user is signed in or not (perhaps a special INITIAL event) or should take a parameter {initial: true} to allow this behavior.

@mikob mikob added the enhancement New feature or request label Oct 13, 2021
@lsrugo
Copy link

lsrugo commented Oct 15, 2021

I would love to see something like this. I want to redirect the user to a login page if they are not signed in but I am having a hard time checking if they are actually signed in or not

@kiwicopple
Copy link
Member

Yes agreed. I'll tag this one with a "help wanted" - if anyone is interested, this can be implemented in gotrue-js after the recoverSession() fucntion call

@kiwicopple kiwicopple added the help wanted Extra attention is needed label Oct 15, 2021
@lsrugo
Copy link

lsrugo commented Oct 15, 2021

We cannot send an event inside the constructor because the event listeners haven't been added yet

@megacherry
Copy link

are there any news regarding the pull request? i didn't want to ask in the pull request.

@Luc069
Copy link

Luc069 commented May 28, 2022

This is the main problem in the supabase world

@abhay187
Copy link

abhay187 commented Jun 7, 2022

I am facing one more problem where the onAuthStateChange event is not triggering on logout.

this video by @dijonmusters Make User State Globally Accessible in Next.js with React Context and Providers shows the problem and workaround. But we need a solid solution.

@J0 J0 added the auth label Jul 18, 2022
@J0 J0 transferred this issue from supabase/supabase Jul 18, 2022
@Stuk
Copy link

Stuk commented Aug 9, 2022

I think the best approach is to represent the initial initialization state as a promise. The API would look something like:

const client = new GoTrueClient(options);

// any time later
await client.initialized();
if (client.user()) {
  // signed in
} else {
  // not signed in
  client.signIn(credentials);
}

This avoids race conditions between the the construction of the client and adding event listeners, and allows one to check the initialization state at any point in the future.

I have created a pull request for this here: #371

@hf
Copy link
Contributor

hf commented Dec 30, 2022

With v2 this is handled. getSession will reuse the initial promise so any waiters on it will resolve properly.

@hf hf closed this as completed Dec 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auth enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants