We’d like to have relatively long session lifetimes for logged in users (2 weeks currently), but have a lot of trouble with API clients and crawlers that create millions of sessions. These sessions take too long to expire and this causes issues with the maximum number of inodes. How can we deal with this? Is it possible to have separate types of sessions, and is there a plugin for this or would we need to develop something ourselves?
Cookie auth on top with longer lifetime, short sessions in general. This way you have the garbage collector do its job, and the ones logged in will automatically have their session silently renewed in the background based on a valid auth cookie present (only possible after login wall).
Specifically, the Cookie Authenticator.
Thank you both. Is it also possible to keep sessions that are used repeatedly for longer, as opposed to sessions that are used once on creation but never reused?
They automatically prolong themselves upon usage, thats the whole difference between session and cookie lifetimes.
Sorry, I was a bit unclear. I would ideally like for unauthenticated users to start with a expiry times of e.g. 1 hour, and then extend to e.g. 2 weeks upon the second request. This would keep UI settings and cookie banners for longer for actual users, while avoiding a lot of sessions from API clients & crawlers. Is something like that possible with e.g. database sessions?
You are overengeneering the issue.
It is also not possible really as the session is started when it is not yet clear what kind of authentication it is.
As stated before: All of that is already happening if you use the above approach, nothing on top needed.
1 Like