I am using node.js + redis for session persistency, however I'm noticing that in nearly every example of redis store or other session persistence, there is a static maxAge or timeout for sessions that you can configure.
It makes sense to me that the session length should be based on the last interaction, and thus allow me to make an update on the timeout. Redis's documentation on its EXPIRE documentation has a section on refreshing the timeoutl
Is refreshing the session timeout bad by design? Should static timeouts always be used?
Edit
My original question was very general since I couldn't find documentation for my specific case and I assumed perhaps it was bad practice! I finally discovered how to do this with Connect + Node after looking at the source code:
end event (to know to update the session)In short, I was looking at the wrong place for documentation. Connect#session documents how if maxAge is assigned a new value, session stores (like connect-redis) should honor that.
There is no such thing as bad design, only bad choices.
Static Max Timeout
A good choice where security is of the utmost importance. Using a tight session timeout, especially with authentication, ensures that the end user is the intended user and not someone who dropped in while the principal user was away from his/her pc or device. The major downside to this approach is negative impact to user experience. The last thing you want is the session going stale just before the user was about to checkout or do something important; with a static timeout, this is inevitable and will happen often enough to piss off users.
Reset Timeout Based on Last Visit
It's safe to say most websites use this approach since it offers a good balance between security and user experience. Resetting the session timeout based on last visit eliminates the issue related to static max timeout, and most ecom and banking websites use this approach, so it's certainly an accepted approach.
Not knowing what you're actually building, I'd say going with the reset approach is probably a good choice nonetheless. The examples you mentioned likely omitted resetting the timeout for brevity reasons, not because it's a bad design.