I notice that im constantly having to relogin which is annoying is it possible to add like a remember me or a way to extend how long an user is kept logged in?
Description
Description
Event Timeline
Comment Actions
I agree with you. It is annoying and the tool itself is designed to hold the session active for 30 days. Unfortunately it’s tool labs that’s killing the sessions.
Comment Actions
Unfortunately it’s tool labs that’s killing the sessions.
Are they being stored on disk or in mysql or ?
Comment Actions
Disk most likely. I'm just using PHP's $_SESSION, and telling it to expire after 30 days. The session holds on my local machine but ends up dying on Toolforge.
Comment Actions
Is this running on Grid Engine or on Kubernetes? Are you expecting local disk storage in either environment to survive a webservice restart? Can you quantify at all the current typical/maximum session persistence duration that you and your users are seeing?
Broadly, I would not personally trust the default PHP session handler for any long term session storage. On Kubernetes this storage will be inside the "pod" (running Docker image) and that will be cleaned up when the service restarts. On Grid Engine the storage would be local to the exec node that PHP process is running on and there is no guarantee that a restart will spawn your new process on the same grid node.
If you want/need long term session persistence I would suggest using either a ToolsDB table private to your tool account or the redis service. If you store in redis, please try to use a random prefix string so that your storage doesn't collide with anyone else using the server. There are some notes about the need for this prefix on wikitech.
Comment Actions
I think it's the grid engine. It's being services by the web service job on the grid. I do not expect it to survive a web service restart and I do not believe the tool has been crashing the webservice. It would be nice if it could survive however. The session tends to last for around 10 minutes before it dies from inactivity. On my local machine, it persists until my machine is restarted.
I've never used Redis or did storage sessions with a DB. I could use some tips on either.
Comment Actions
Per the suggestion of @bd808, I have created my own session handler that uses the existing DB to store the data in an encrypted state. I have extensively tested the new handler and it seems to work. All data is encrypted with openssl. Please test and see how the session times hold up with this new handler.
Released in the GUI v1.2beta3 release.
Comment Actions
I had to switch back to PHP's default handler. The DB handler doesn't seem to like Toolforge very much as it completely broke the tool. I'll have to investigate tomorrow.
Comment Actions
So the problem is for some reason the DB Session modifications don't seem to agree with the Webservers. When a new session is started, it's able to load the first page. The second page load causes a 500 error to be returned.
The session is initialized at https://github.com/cyberpower678/Cyberbot_II/blob/test/IABot/www/Includes/OAuth.php#L53 which is implemented at https://github.com/cyberpower678/Cyberbot_II/blob/test/IABot/www/Includes/OAuth.php#L53 with subsequent handlers below it. The DB aspect of the session handlers are found at https://github.com/cyberpower678/Cyberbot_II/blob/test/IABot/www/Includes/OAuth.php#L53 and the functions below it.
Comment Actions
As a note AES-256-CBC-HMAC-SHA256 is not supported on Toolforge so is instead using AES-256-CBC-HMAC-SHA1
Comment Actions
The problem was that AES-256-CBC-HMAC-SHA1 was causing segmentation faults so I changed to yet another encryption method and redeployed. Seems to be stable now. I'm observing to see if the sessions are persistent now or not. They should be persistent for up to 30 days before they die.