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

Intermittent Logout Failure with Custom Session Store #1531

Closed
6 tasks done
k-1ee opened this issue Nov 2, 2023 · 2 comments
Closed
6 tasks done

Intermittent Logout Failure with Custom Session Store #1531

k-1ee opened this issue Nov 2, 2023 · 2 comments
Labels
question Further information is requested

Comments

@k-1ee
Copy link

k-1ee commented Nov 2, 2023

Checklist

Description

In the past, stateless sessions were problematic for logouts in our application due to the race condition between clearing the user agent's cookies & a concurrent network request that sets a valid cookie.

To solve this, we've implemented a custom session store using Redis (by following this example). As a result, the success rate of logouts have improved drastically -- however, I'm still noticing that logout will fail at times. This failure seems to happen at the application session layer since there is a "Successful Logout" log in our Auth0 tenant, but the application session is still active.

FWIW:

  • logout failure occurs roughly every 1 in 10 attempts
  • when logout fails, a subsequent logout seems to work fine

All that to say, I suspect there may be a race condition given the intermittent nature of the issue. Ideally, having stateful sessions should eliminate this issue.

Reproduction

  1. Set up store with Redis (.get/set/delete methods)
  2. Supply store as config.session to initAuth0
  3. Invoke logout handler (/api/auth/logout)

Additional context

No response

nextjs-auth0 version

2.6.3

Next.js version

13.4.12

Node.js version

18.18.2

@adamjmcgrath
Copy link
Contributor

Hi @k-1ee - thanks for raising this

If you have lots of sets on the session store for the same key concurrently with your delete, I can imagine that you would still have concurrency issues - where a request may start before the logout request, but it's set to the store may happen after the logout's delete (and so re-establish the session)

The issue is quite well described in tj/connect-redis#328

The easiest solution would be to limit the number of set's to the store. This SDK writes to the store on every request, but you can configure it not to do this (by disabling session.rolling) or you can configure it to roll the session more selectively (using session.autoSave = false and touchSession)

I see in connect-redis that there was also an attempt to modify the store (using a slow delete) to prevent this tj/connect-redis#333, but this was later reverted tj/connect-redis#347

@adamjmcgrath adamjmcgrath added the question Further information is requested label Nov 3, 2023
@k-1ee
Copy link
Author

k-1ee commented Nov 6, 2023

@adamjmcgrath - There definitely does seem to be a lot of sets taking place. I had a feeling that this may be the case -- appreciate the insight!

I'll close this for now as your suggestions provide good direction into mitigating the issue.

@k-1ee k-1ee closed this as completed Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants