Flyspray - The bug killer!

As a temporary fix:

Try changing session.gc_maxlifetime to a bigger value in PHP's ini settings.
E.g. session.gc_maxlifetime=7200 for a 2h session timeout without activity.
Default seems to be only 24 minutes..

There are also other session settings involved with the garbage collection(deleting old session files), see http://php.net/manual/de/session.configuration.php

Flyspray uses currently quite default session settings and the session ($_SESSION) is stored as file (see session.save_path) and managed (garbagecollection) by the webserver.

So when you send a form back to Flyspray after gc_maxlifetime between opening the form and submitting and no other activity by you in Flyspray, the matching session-file could be deleted by the webserver meanwhile and you get the 'wrong token' message even if you sent the correct anti-csrftoken and cookies.

How session.gc_maxlifetime can be effectivly set depends on webserver config:

• php.ini
• or adjustable by .htaccess
• or settings in the frontend of a shared hosting provider
• or simply within includes/fix.inc.php

  ini_set('session.gc_maxlifetime',7200);

Ideally we just set that within Flyspray, for guests lets say 30 minutes, and longer for registered users, staff peoples that keep a Flyspray browser tab open all day long.
(untested if possible without big changes)

To see the session settings, try add a file info.php to directory scripts:
scripts/info.php

<?php
if (!defined('IN_FS')) {
        die('Do not access this file directly.');
}
if (!$user->perms('is_admin')) {
        Flyspray::show_error(4);
}
echo phpinfo();
?>

And view it with /?do=info

section session (Don't forget to delete scripts/info.php after test)

Maybe this problem goes away when online notification is implemented in future in a way the browser checks periodically for notification updates (lets say every minute), so the session timer is updated every minute and so the session on the webserver doesn't timeout while Flyspray browser tabs are open.

Please let me know if one of my suggestions worked.

For now I've raised session.gc_maxlifetime to 14400 which ought to be more than enough time unless someone is literally camped on the page all day.

That should work for now, but it would be nice if the comment form wasn't subject to this sort of thing at all.

Just wanted to come back and mention that changing those settings in PHP has had no effect. The comment form still invalidates way too fast.

Since one cannot comment without being logged in anyway, could it be made optional to turn this feature off at least?

Since one cannot comment without being logged in anyway, could it be made optional to turn this feature off at least?

Sorry, token prevents a logged in user (someone with a valid session and cookie) can be used/tricked as victim to send bad requests by another website (or even same website) to your flyspray in the name of the user.

Maybe your server is doing the /tmp cleaning and doesn't care about your local php flyspray settings? Do you see your session files in /tmp or are they stored somewhere else? Which server/os?

I know it is annoying, maybe show a warning in the admin area if the session time stuff is too short?

I suggest to really find the session cleaning 'dude' and 'tell' him to keep sessions live longer.

A little relaxation could be done by me to check the token when hitting the preview button (only dokuwiki editor). At the moment the token seems not to be checked for preview (because it doesn't save anything to database)
So when the token check fails on preview we could show a warning too (wrong token, better copy text somewhere before hitting the save button) and so the user knows - f**k token, and copies the written comment to a text editor/notepad and doesn't loose at least that written text. (lame, I know)

Alternatives

(I never worked with localStorage yet, but could be also a solution for a simple  'offline'-fallback Flyspray.)

Maybe http://stackoverflow.com/questions/8372189/php-sessions-expire-too-soon?rq=1 helps?

I have a debian vserver and there exists a script /usr/lib/php5/sessionclean
that seems to be called by cronjob

grep -r sessionclean *
cron.d/php5:09,39 *     * * *     root   [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean

From https://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime :

Note: If different scripts have different values of session.gc_maxlifetime but share the same place for storing the session data then the script with the minimum value will be cleaning the data. In this case, use this directive together with session.save_path.