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

[fix] Call SIGNED_OUT event where session is removed #854

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

bombillazo
Copy link

@bombillazo bombillazo commented Feb 16, 2024

What kind of change does this PR introduce?

This adds the SIGNED_OUT event missing in some logic that clears/logs out the session.

What is the current behavior?

#853

@bombillazo bombillazo changed the title fix: keep existing session on auth functions if they fail [fix] Keep existing session on auth functions if they fail Feb 16, 2024
@bombillazo
Copy link
Author

Any feedback on this @kangmingtay @hf ? We're needing to patch this library whenever a new version is released.

@bombillazo
Copy link
Author

Any updates here?

Comment on lines 483 to 485
if (currentSession) {
await this._saveSession(currentSession)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not sure why it's necessary to preserve the existing session when one calls the signup method - we always want to remove the session when signup is called to prevent any possibilities of the user logging in as someone else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this applies to all the other sign-in methods too - if you're signing in, there won't be any session in the first place, else you'd be logged in already

Copy link
Author

@bombillazo bombillazo May 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This truly depends on the UI implementation. We may need to allow logged-in users to switch accounts directly so it is possible to call sign-in/sign-up. Currently, if something fails, the user is kicked out of their current session.

In addition, I don't see how this would log a user into someone else's account. Either the sign-in is successful, and the current session switches to the new one, or it fails, and you keep the existing one. If you were never logged in, you stay logged out.

Copy link
Contributor

@j4w8n j4w8n May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the team wanted to go down this path, you could simplify a lot of these methods by moving the _removeSession call to right before the _saveSession calls. There would be a few exceptions to that though.

I've seen more and more discussions about people trying to implement a "switch account" feature; or they already have, but recent changes have broken their implementations.

Copy link
Author

@bombillazo bombillazo May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I just wasn't sure if some logic was dependent on having no session while executing, so I preferred keeping it and reverting at the end.

Hopefully, we can remove the current limitation, be it by removing _removeSession where not necessary or, as my PR suggests, restoring the session on fail.

This is already working for us in production, we patch this library in our app for this behavior, but we'd prefer if the lib had it working natively.

@jczstudios
Copy link

Any updates on this, it's breaking our production Electron app, seems that when a request fails, the user just gets signed out entirely.

Copy link
Contributor

@j4w8n j4w8n left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate the review tag, but this one will ultimately need to be looked at by kangmingtay or hf. Last I knew, the team's time was limited; so, who knows if/when they'll consider this PR further.

@bombillazo
Copy link
Author

Ok, I'll mention @hf so they'll be aware and have visibility on this fix request.

@kangmingtay
Copy link
Member

sorry @bombillazo i was on vacation last week - i'll be looking into this further to see if we can just do away with removing the session prematurely before hitting the underlying auth endpoint - not too sure if it will cause any unintended breaking changes here so we need some time to test this out

@kangmingtay
Copy link
Member

@bombillazo i've made a separate PR (#915) to address this - would be great if you can take a look at it too

kangmingtay added a commit that referenced this pull request Jun 7, 2024
## What kind of change does this PR introduce?
* Replaces #854 
* Fixes #853, #904 
* We don't need to remove the existing session prematurely. This causes
some issues when users want to implement some sort of switch-account
functionality since the existing session will always be removed
regardless of whether the signup / sign-in attempt succeeds.
* It's safe to remove `_removeSession` since calling `_saveSession`
multiple times will just replace the existing session
@bombillazo
Copy link
Author

bombillazo commented Jun 18, 2024

Hey @kangmingtay thanks for the PR, I merged the current repo to my branch and the only thing missing is a few lines of code to emit the SIGNED_OUT event during the _recoverAndRefresh function if the session is ultimately removed.

This means #904 is fixed but #853 is still open.

@bombillazo bombillazo changed the title [fix] Keep existing session on auth functions if they fail [fix] Call SIGNED_OUT event where sessino is removed Jun 18, 2024
@bombillazo bombillazo changed the title [fix] Call SIGNED_OUT event where sessino is removed [fix] Call SIGNED_OUT event where session is removed Jun 18, 2024
@bombillazo
Copy link
Author

bombillazo commented Jul 16, 2024

Any update here? This fixes #853

@bombillazo
Copy link
Author

Hey @kangmingtay , any update on this issue?

@bombillazo
Copy link
Author

bombillazo commented Sep 9, 2024

Hey @kangmingtay @hf , I know 2.65.0 was released but this is missing to truly close #853

@bombillazo
Copy link
Author

bombillazo commented Sep 29, 2024

@kangmingtay @j4w8n @hf Could this be rechecked please? We still need to run auth-js patched on our side due to this. This is needed to resolve #853 which was incorrectly marked as completed

@j4w8n
Copy link
Contributor

j4w8n commented Sep 29, 2024

I see you moved the SIGNED_OUT event trigger into _removeSession. I understand wanting to move it there, but I still think there are one or two cases where calling _removeSession shouldn't necessarily trigger the event.

However, this isn't my party, and the maintainers may be fine with it. I'm not sure it would hurt anything.

Copy link
Contributor

@j4w8n j4w8n left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ultimately up to the maintainers, but I wrote a couple of things.

@@ -1891,6 +1891,7 @@ export default class GoTrueClient {
this._debug(debugName, 'session is not valid')
if (currentSession !== null) {
await this._removeSession()
await this._notifyAllSubscribers('SIGNED_OUT', null)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the session isn't valid, then no one should've been signed in to begin with; so I'm not sure if triggering the event here is strictly necessary. Is it causing an issue, or are you just trying to cover all bases?

Copy link
Author

@bombillazo bombillazo Sep 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_recoverAndRefresh could be called with someone already in a signed in state, like from the _onVisibilityChanged function. Also, we may have cookies during the client initialization we need to clear if the session is invalid, and by not triggering this event in the initial "no one is signed in to begin with" state, we get inconsistent issues. This is what is happening in our case. So, the way to avoid this is to trigger the SIGNED_OUT event every moment the session is removed, regardless of why it was removed. We also have logic that depends on reacting to the session that no longer exists in the client. This is also how it is described in the documentation:

image

@@ -2085,11 +2081,11 @@ export default class GoTrueClient {
// finished and tests run endlessly. This can be prevented by calling
// `unref()` on the returned object.
ticker.unref()
// @ts-ignore
// @ts-expect-error TS has no context of Deno
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this needed here, since the Deno scenario is covered below? Or maybe the Deno check should happen first?

Copy link
Author

@bombillazo bombillazo Sep 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO @ts-expect-error is a much better way to document why a typescript error needs to be ignored compared to @ts-ignore, I simply replaced the existing ts comment with this one.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know of a way to check for Deno without TS complaining

@bombillazo
Copy link
Author

Thanks @j4w8n for the questions/feedback, hopefully this can be reviewed by the corresponding devs to keep the ball rolling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants