bradtaniguchi
commented
5 months ago Hello, thanks for opening up the issue.
I'll wait for @JLuboff to get back on this one, but I'll throw out my interpretation first.
I agree, there appears to be a gap in functionality, where the autoRemoveCallback is executed after the removal already occurred. Its my understanding you'd want a hook, something like "preRemoveCallback" which is called before the delete is execute. I'm not sure if any returned values could/should be used to possibly change the behavior of the actual executor (of it that even makes sense here) but I believe adding something that is called before the removal occurs, (and is waited for) makes sense.
Again though, want to get @JLuboff opinion on it 👍🏼
Greensahil
JLuboff
Is your feature request related to a problem? Please describe. Yes, the problem is related to the lack of a callback or hook that is invoked immediately before a session expires and is deleted from the database. Currently, the connect-mssql-v2 library provides the autoRemoveCallback option, which is triggered after the expired sessions are deleted. However, there is no way to execute custom logic or perform necessary actions, such as auditing, right before the session expiration process begins.
Describe the solution you'd like The desired solution is to add support for a callback function that is invoked just before the session expiration process starts. This callback should be configurable through a new option, such as beforeExpireCallback, which accepts a function.
The destroyExpired method should be modified to execute the beforeExpireCallback (if provided) before running the delete query on the sessions table. The callback should receive relevant information, such as the session ID or session data, to allow for custom logic based on the expiring session.
Describe alternatives you've considered Another alternative is to use a separate cron job or background process to query the sessions table, identify expiring sessions, and perform custom actions before deleting them. However, this approach can be complex to set up and maintain, and it may introduce race conditions if the session is modified or extended after being identified as expired.
Additional context In my application, I implement auditing functionality to track important user actions, such as sign-ins and sign-outs, by writing relevant information to an audit table. However, when a session expires automatically due to inactivity or reaching the expiration time, this library directly deletes the session data from the database without providing any hooks or callbacks that allow me to perform auditing or other necessary actions before or after the session expiration.