View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012492||mantisbt||bugtracker||public||2010-10-27 08:50||2017-09-10 06:33|
|Target Version||Fixed in Version|
|Summary||0012492: Complete input get lost when timeout or not filling all required fields (when using ssl/https)|
When not all required fields are filled, an error message occurs. It says to go back with the browser button fo fix the error. But when using SSL, the browser will not restore the field values so anything typed in the form get lost.
|Tags||No tags attached.|
|duplicate of||0009609||acknowledged||Blank input fields lead to complete loss of typed in data if HTTPS is used|
|related to||0009323||closed||jreese||Browser caching broken since 1.1.2|
|has duplicate||0013299||closed||dregad||when sitting at bug for long time and adding long note, erroneously claims I submitted twice, loses my note|
|has duplicate||0013548||closed||rombert||form field is reset|
|has duplicate||0013586||closed||rombert||form field is reset|
|related to||0013246||closed||dregad||APPLICATION ERROR #2800 when submitting notes|
|related to||0023326||closed||atrol||preventing data loss|
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
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?
|2010-10-27 08:50||mwyraz||New Issue|
|2010-10-29 04:31||yw84ever||Note Added: 0027191|
|2011-03-14 11:40||johsin18||Note Added: 0028416|
|2011-03-14 13:07||dregad||Note Added: 0028417|
|2011-09-09 03:55||dregad||Relationship added||has duplicate 0013299|
|2011-09-09 05:07||jmichae3||Note Added: 0029668|
|2011-09-09 05:32||dregad||Note Edited: 0029668||View Revisions|
|2011-10-27 04:58||djsmiley2k||Note Added: 0030084|
|2011-11-02 10:07||mwyraz||Note Added: 0030147|
|2011-11-02 11:06||dregad||Relationship added||related to 0009323|
|2011-11-02 11:13||dregad||Note Added: 0030148|
|2011-11-03 17:36||jmichae3||Note Added: 0030156|
|2011-11-03 17:40||jmichae3||Note Edited: 0030156||View Revisions|
|2011-11-22 12:15||rombert||Relationship added||has duplicate 0013548|
|2012-01-20 10:57||Alain Frisch||Note Added: 0030977|
|2012-01-31 09:04||dregad||Relationship added||related to 0013246|
|2012-06-22 06:05||atrol||Relationship added||duplicate of 0009609|
|2012-06-22 06:05||atrol||Status||new => resolved|
|2012-06-22 06:05||atrol||Resolution||open => duplicate|
|2012-06-22 06:05||atrol||Assigned To||=> atrol|
|2012-07-02 03:20||atrol||Status||resolved => closed|
|2017-09-10 06:33||atrol||Relationship added||related to 0023326|