signOut does not clear user jwt from gotrue authorization header allowing gotrue operations and exposing user jwt

[GaryAustin1]

Bug report

Describe the bug

This is from a user discussion on DISCORD

Although signOut clears the session data from local storage, it appears it leaves the user jwt in the gotrue headers object and in a second object called changedAccessToken.

If you run getUser() after signOut a request to the server goes out and the user data is returned.
Although database API calls revert to the anon key, the jwt could also be copied and used until it expires.

A temporary solution is probably to set the client "object" to null, or reinitialize the client if further work needs to be done after signout.

To Reproduce

console.log('login')
        const {data} = await supabase1.auth.signInWithPassword({email: 'email', password:'pass'} )
        console.log('login ',data)
        console.log('signOut ',await supabase1.auth.signOut())
        console.log('getSession ', await supabase1.auth.getSession())   //null
        console.log('supabase ',supabase1)  //see image below
        const result = await supabase1.from('realtest').select()  //authentication header anon
        console.log ('getUser ', await supabase1.auth.getUser())  //auth header has user jwt and returns user data from server

Supabase object after signOut()

getUser going out with a user jwt after signOut().

Expected behavior

SignOut() should remove any jwt info from memory and certainly no allow gotrue operations to continue.

It is understood there is a risk of unexpired jwts after signOut, but they should not be left around for someone to find or use after signOut().

System information

supabase-js 2.0.4

[GaryAustin1]

This is a slightly different issue, but related to auth having its own headers...

.getUser(jwt) if called while using service_role sets the authentication header in auth to the User JWT.
The supabase client header still stays service_role, but if you make further admin auth calls after doing a .getUser call they will be rejected with 401.

If this is desired behavior for getUser(jwt), then this should be documented as users are running into this server side.

This image is of auth's headers in the supabase "object".

[j4w8n]

I was able to reproduce this. Resolved by adding the following to dist/main/SupabaseClient.js in the @supabase/supabase-js codebase. This would be src/SupabaseClient.ts here. I believe this is the correct spot to make these changes; but I honestly don't know, as I struggled to figure out how headers get set (possibly in a function passed to fetch here, because _getAccessToken() seems to call getSession() and then return the access token for fetch's use).

  _handleTokenChanged(event, token, source) {
    if ((event === 'TOKEN_REFRESHED' || event === 'SIGNED_IN') &&
      this.changedAccessToken !== token) {
      // Token has changed
      this.realtime.setAuth(token ?? null);
      this.changedAccessToken = token;
    } 
    else if (event === 'SIGNED_OUT' || event === 'USER_DELETED') {
      // Token is removed
      
      this.realtime.setAuth(this.supabaseKey);
+     this.changedAccessToken = undefined;
+     this.auth.headers.Authorization = `Bearer ${this.supabaseKey}`;
      if (source == 'STORAGE') 
          this.auth.signOut();
    }
  }
}

[j4w8n]

This is a slightly different issue, but related to auth having its own headers...

.getUser(jwt) if called while using service_role sets the authentication header in auth to the User JWT. The supabase client header still stays service_role, but if you make further admin auth calls after doing a .getUser call they will be rejected with 401.

If this is desired behavior for getUser(jwt), then this should be documented as users are running into this server side.

This image is of auth's headers in the supabase "object".

I went ahead and created issue #531 for this.

[thorwebdev]

I think the root cause of this might be supabase/supabase#5990

[j4w8n]

#541 looks to have resolved all but the changedAccessToken in the supabase-js client.

I assume a simple this.changedAccessToken = undefined around line 297 here would do it. But wasn't sure if there was another way y'all wanted to handle it.

[hf]

Added a PR for the suggested change by @j4w8n. Will close this issue.