Storing sessions in db, but use secondary storage for active sessions, doesn't revoke properly
Database related
The behaviour I'm after is:
- only use secondary storage when fetching a session, using getSession, or any other methods of fetching active sessions
- use database for historical context & debugging only
This is for an application where auditing, session revocation, and latency are all important.
To be clear, for the testing carried out below I disabled cookie caching, so that's not the problem.
I have secondary storage setup, and I've experimented with both session.storeSessionInDatabase and session.preserveSessionInDatabase, however I can't seem to figure out the correct combination (or perhaps an extra setting) that allows this behaviour?
The combinations I've tried result in:
- nothing being stored in the database
- sessions being deleted from the database also
- the session being correctly stored in the database, and staying after being revoked - api.getSessions returns the correct sessions, however actually querying api.getSession from the revoked session (i.e. using cookie) still works successfully until I manually remove it from the database also (it looks like it's using the database session as a fallback).
Can anyone help me out with this?
Edit:
the "storeSessionInDatabase" option comment says "Reads are always done from the secondary storage"; this seems incorrect.
Looking at the source code for the "findSession" function, it always seems to call the database if storeSessionInDatabase is true and a session wasn't found in secondary storage - this makes the above implementation very difficult and hacky, I believe.
The only solution I can currently think of is making a custom database adapter that forces a soft-delete on session rows, and doesn't return them when queried, to better-auth.
- only use secondary storage when fetching a session, using getSession, or any other methods of fetching active sessions
- use database for historical context & debugging only
This is for an application where auditing, session revocation, and latency are all important.
To be clear, for the testing carried out below I disabled cookie caching, so that's not the problem.
I have secondary storage setup, and I've experimented with both session.storeSessionInDatabase and session.preserveSessionInDatabase, however I can't seem to figure out the correct combination (or perhaps an extra setting) that allows this behaviour?
The combinations I've tried result in:
- nothing being stored in the database
- sessions being deleted from the database also
- the session being correctly stored in the database, and staying after being revoked - api.getSessions returns the correct sessions, however actually querying api.getSession from the revoked session (i.e. using cookie) still works successfully until I manually remove it from the database also (it looks like it's using the database session as a fallback).
Can anyone help me out with this?
Edit:
the "storeSessionInDatabase" option comment says "Reads are always done from the secondary storage"; this seems incorrect.
Looking at the source code for the "findSession" function, it always seems to call the database if storeSessionInDatabase is true and a session wasn't found in secondary storage - this makes the above implementation very difficult and hacky, I believe.
The only solution I can currently think of is making a custom database adapter that forces a soft-delete on session rows, and doesn't return them when queried, to better-auth.
