Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix frequent Gatherling logouts by introducing the concept of db-held…
… sessions Despite a bunch of monkeying around with a cookie_lifetime setting and ini_set calls, gatherling.com generally logs you out after 24 minutes of inactivity. The root cause of this problem is abusing the PHP session and trying to make it a thing that lives for 60 days instead of 24 minutes/until you close your browser (the default). The reason extending the session does not work out despite the messing around with ini_set and so on is because most unix-based installs of PHP add a cron job that checks every "active" php.ini on the sever for the session timeout, declares the shortest time found the winner, and kills all older sessions (making the files storing them empty). The fix here is to let PHP sessions be PHP sessions. We no longer try to make them live 60 days. Instead we cookie you with a remember_me cookie against which we store your session details in the database. This cookie lives for 60 days, a fact which is also enforced in the database. If either the cookie or the db row go away then your session will no longer be persisted. We update expiry in both places every time you complete a request in a shutdown function. So you'll stay logged in forever as long as you visit every sixty days. Because there are 150 mentions of "session" in the existing codebase I went for an implementation that is agnostic about what is actually IN the session. We just JSON encode whatever it is and put it in the db. Eventually perhaps all session access will flow through Gatherling\Auth\Session and we can be a bit less generic about it all. We delete all expired sessions on every request from every user. If this ends up being unnecessarily busy we can create a cron job or something similar. Because it will PHP Fatal Error before it runs in web you have to run db-upgrade from the commandline for this migration. The remember_me cookie lives forever and any attempt to remove it will just result in recreation. Even if it's just remembering you are an anonyous person and your session is empty. If that ends up being unnecessarily busy we can revisit. We store expiry in the database not "last active" although either can be derived from the other by adding/substrcacting 60 days.
- Loading branch information