User Forced to Go Through Login Flow Twice After Session Expired

[tyler-dane]

Prerequisites

• Using an up-to-date main branch

Expected Behavior

1. User tries to access Compass after an extended time (after their session expired)
2. User redirected to login screen
3. User presses login button, prompting Oauth dialog
4. User confirms Oauth dialog
5. User's sync is initialized
6. Compass redirects to home page
7. User can access and edit events like normal

Current Behavior

1-6: same
7: Compass redirects to home page, which triggers requests for /api/event....
8. The request fail with 401 unauthorized from SuperTokens
9. User is redirect to login page
10. User clicks through sign in button and dialog AGAIN
11. User is redirected to home page
12. User can finally access and edit events like normal

Steps to Reproduce

Here's what the devtools like after 'successfully' going through the OAuth flow. Notice the 401 'unauthorised' message from Supertokens.

Here are the logs that accompany the above scenario:

# tries to access events, 401 correctly return (session expired)
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 154.687ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 148.039ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 1.188ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 1.079ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 1.112ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.927ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.744ms Sat, 09 Mar 2024 21:01:25 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.681ms Sat, 09 Mar 2024 21:01:25 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.708ms Sat, 09 Mar 2024 21:01:25 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.650ms Sat, 09 Mar 2024 21:01:25 GMT

# after going through oauth dialog box
68|backend  | 24-03-09 21:01:41 [debug] app:sync.helpers: REMINDER: Channel will expire in 7200 minutes (5 days)
68|backend  | 24-03-09 21:01:41 [warn] app:user.service: Re-syncing google data for user: 651488733aa260d5183921c1
68|backend  | 24-03-09 21:01:41 [debug] app:sync.service: Stopping all gcal event watches for user: 651488733aa260d5183921c1
68|backend  | 24-03-09 21:01:41 [debug] app:sync.service: Skipped stop for calendarId: test1@gmail.com due to missing field(s):
68|backend  |             channelId: undefined
68|backend  |             resourceid: eRqPWi.....
68|backend  | 24-03-09 21:01:42 [debug] app:sync.helpers: REMINDER: Channel will expire in 7200 minutes (5 days)
68|backend  | 24-03-09 21:01:42 [info] app:sync.service: Sync initialized for channelId: a4c00712-85d1-......
68|backend  | 200 POST /api/sync/gcal/notifications 0.829ms Sat, 09 Mar 2024 21:01:42 GMT
68|backend  | 200 POST /api/oauth/google 1814.245ms Sat, 09 Mar 2024 21:01:43 GMT

# but the next request still fails with the same 401 error (why???)
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.862ms Sat, 09 Mar 2024 21:01:43 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.620ms Sat, 09 Mar 2024 21:01:43 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.634ms Sat, 09 Mar 2024 21:01:43 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.584ms Sat, 09 Mar 2024 21:01:43 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.683ms Sat, 09 Mar 2024 21:02:10 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.781ms Sat, 09 Mar 2024 21:02:10 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.587ms Sat, 09 Mar 2024 21:02:10 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.600ms Sat, 09 Mar 2024 21:02:10 GMT

# creating an event in Google Calendar is triggered (ie, the sync is setup correctly)
68|backend  | 24-03-09 21:02:24 [debug] app:sync.service.helpers: updating: "synced?"  | eRq......
68|backend  | 200 POST /api/sync/gcal/notifications 248.032ms Sat, 09 Mar 2024 21:02:24 GMT

# user goes through Oauth again
68|backend  | 200 POST /api/oauth/google 743.598ms Sat, 09 Mar 2024 21:07:03 GMT

# now it works
68|backend  | 200 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 111.797ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 42.320ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 36.655ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 33.446ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 16.417ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 12.486ms Sat, 09 Mar 2024 21:07:03 GMT

More backend logs, this time as a screenshot:

Possible Solution (Not obligatory)

• It seems like Supertokens isn't creating a new session the first time. Perhaps we need to call their API differently when signing in for the first time.

Context

This affects users by giving them the impression that the sign in is broken (it kinda is), which causes them to give up before trying again a second time.

[DiegoMutre]

Hey @tyler-dane 👋, I'm interested on this issue. How can I reproduce the scenario? Should I create a new account? When does the session expire?

[tyler-dane]

Hey @DiegoMutre thanks for your interest. I'm honestly not sure about an easy way to reproduce it consistently.

The painful ways would be to:

1. Mock the Supertokens service, returning a 401
2. Or manually expiring a supertokens session

Since there's a lot of unknowns here, the best way might be to just reach out to the Supertokens support team on Discord, which is pretty responsive with stuff like this. They'd know more than I about how to fix this.

[DiegoMutre]

Hey @tyler-dane! I haven't tried any of the ways you suggested me yet, but I tried something else: I set the access_token_validity to 60 seconds and the refresh_token_validity to 2 minutes in the SuperTokens Development Environment Configuration

So, I got the session to "expire" because it logs me out after the 2 minutes, but the issue doesn't happen, even if the account was just created.
Btw, I can't remember the default values for access_token_validity and refresh_token_validity because the change took effect the next day, but I remember that the default time for refresh token validity was around a year or more (in minutes).
However, I think on trying in the production environment of the SuperTokens to see what happen.

Anyway, I will try to reach out to the SuperTokens support team on Discord to get more info. You can try doing something like I did with the SuperTokens config to see if the same happens.

[tyler-dane]

Hey @DiegoMutre - that's great that you're coming up with creative ways to reproduce this.

While this issue might not occur after the method you described, I confirmed today that it still occurs in production :/

I updated the description with another screenshot to validate this.