I’m using Kirby’s session feature to handle “front-end users”. I’m not using “Kirby users”, just the $kirby->session() object to store an id of the logged in users.
Now, when someone logs in, I need to disconnect the other sessions of that same user.
For this, my idea was to enumerate all the sessions and eventually delete the “other” session files for that user id. So, essentially, I would need to be able to “filter sessions by a property stored in them”.
Is there any PHP API offered by Kirby that helps me do this or would I be better off just reading and parsing the files in the site/sessions folder?
If doing it myself, skimming over the FileSessionStore source code I’ve noticed that it sets some file locks on the session files… How long are those kept? Could they interfere with what I’m trying to do?
Kirby does not provide an API for looking up sessions by their content.
However there’s an easier solution for what you are trying to do: In a user.login:after hook, touch() the .htpasswd file of the user and update the login timestamp in the session. This will automatically invalidate all other sessions. Kirby uses this when the user password is changed.
Thanks for the answer. I’m not using Kirby users, just Kirby sessions, so unfortunately I can’t use the hook and existing login timestamps, but in the end I’ve done something similar: I now store the session id in the user database when someone logs in, and in subsequent requests I check if the current session id corresponds to the one in the db.
Anyhow, I think some utilities to load arbitrary sessions could be handy.
At the moment, it looks like one can read a session from file with Kirby only by knowing its “token”, which however includes info that is stored in the session file itself (and obviously in the user’s cookie).
Sorry, I missed that you don’t use Kirby users in your first post.
The token includes a key that is only in the user’s cookie. This is by design to prevent session hijacking from a directory listing attack and to prevent manipulation of the session data by attackers with write access. It is a design choice I’m not sure I would make again because of all the gotchas it introduces and the limited benefit. But it’s the reason why the current implementation can not support accessing arbitrary sessions without the full session token. Maybe we can rewrite the session implementation in a much simpler way in the future.