I had a similar issue. Users were leaving the entry open for a long time, eventually editing bit by bit, then submitting. By the time that happened though, MantisBT showed that the session had timed out. Browser Back, data had been lost (though it seems some browsers were capable of storing it).

Solution has been twofold: training on using MantisBT ;) and increasing the time before PHP garbage collection occurs.

; After this number of seconds, stored data will be seen as 'garbage' and

; cleaned up by the garbage collection process.

; http://php.net/session.gc-maxlifetime

; default: session.gc_maxlifetime = 1440

session.gc_maxlifetime = 86400

SourceForge supports MantisBT as "hosted app", and users are forced to use https there. So this bug applies for all the proejcts there, and this is a very annoying bug.

Nice catch with the SSL here ! I have been wondering for some time why this was happening on the timeouts.

APPLICATION ERROR #2800

Invalid form security token. Did you submit the form twice by accident?

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

EDIT: dregad, adding additional text from jmichae3's note 0013299:0029669

I don't know how much this helps. the tokens I make for my apps are time-based+ a few other things - if you stored yours in a session, HOW you make use of it is very important to having success in a form. I typically put the token in a hidden form field rather than session only, the reason being that SESSIONS EXPIRE.

I may get back to finishing my form entry after a 1-2 days do to the nature of life in general happening. I can't control everything in life.

I don't know what code is killing the security token.

Also have this issue. Users screaming and shouting '(Personally don't know why they can't just hit submit at the time - add extra notes when you need to but hey!)'

Increasing garbage collection timeout would be ok if I can set it for JUST mantisBT, but I have no idea how I'd do this so....

I finally solved the problem. Because some users complained about caching issues, i tired to find out, why some special cache-control headers where set with mantis. I finally found out that these headers where caused by
core/session_api.php: session_cache_limiter( 'private_no_expire' );

After changing it to session_cache_limiter( 'none' ); the cache issues disapeared.

And the best: the problem described above disapperared as well!

Now on errors after input, i can simply press browser-back, i can press reload to obtain a new transaction id and i can edit and send again - even with SSL enabled.

This setting in the session api was introduced as part of a fix for 0009323.

John, as author of this change could you comment on validity of fix proposed by mwyraz ?

it takes me a long time to edit bugs. the best solution is one which does not timeout on me. one which is not time-based. sometimes it takes me all night or 2 days (type in at night, finish in morning with machine on if I have to) to type in a bug report. if it's fixed and this is not a problem, yahoo!

We're also regularly confronted to this timeout problem, but on regular http connections (not https). This happens for new bugs and new notes. It is of course very annoying to loose a carefully written text... Should I open a new bug for it, or assume it will be fixed at the same time as the https case?