Intermittent Logout Failure with Custom Session Store

[k-1ee]

Checklist

• The issue can be reproduced in the nextjs-auth0 sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

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]

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

[k-1ee]

@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.