Flyspray - The bug killer!

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Information
  • Category Backend/Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 1.0-beta
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray - The bug killer!
Opened by Arthmoor - 22.11.2016

FS#2316 - "wrongtoken" is displayed if the comment box is left sitting too long

I understand this is likely due to some sort of XSS protection, but the delay doesn’t appear to be long enough to be useful for a lengthy comment to be posted. I’ve now lost two detailed comments in our tracker because the software threw everything out and generated a meaningless error.

Further, attempting to do the normal thing and making the browser resubmit the page results in Flyspray throwing “Error #3” something something repeated action and causing a redirect to the homepage.

Surely there has to be a better way to handle this that doesn’t incur data loss?

Project Manager
peterdd commented on 22.11.2016 22:45

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.

Project Manager
peterdd commented on 22.11.2016 22:47

Please let me know if one of my suggestions worked.

Arthmoor commented on 23.11.2016 04:23

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.

Arthmoor commented on 30.01.2017 06:04

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?

Project Manager
peterdd commented on 11.02.2017 06:15
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

  1. Storing the comment content client based while writing in some of the available HTML5 storages: localStorage (or sessionStorage, IndexedDB, Web SQL Database)

So when the submit fails (or you accidently close the browser), the localStorage works as backup ..

(I never worked with localStorage yet, but could be also a solution for a simple  'offline'-fallback Flyspray.)
  1. I work with another php software(a shop) that doesn't have such problems. But that shop uses a mysql database table as session handler for storing the $_SESSION, so the shop software has full control over the duration of each session.

Both alternatives would need some work for flyspray, so better analyze why the default php session handling is not good enough.

at all: other ideas?

Project Manager
peterdd commented on 11.02.2017 06:46

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing