View Issue Details

IDProjectCategoryView StatusLast Update
0024039Open CASCADEWebsite:Trackerpublic2015-01-21 10:34
ReporterabvAssigned Toaiv 
PriorityhighSeveritymajor 
Status closedResolutionfixed 
Summary0024039: Mantis session timeout and error "Invalid form security token"
DescriptionRegistering or editing a Mantis issue, or adding a comment, often takes long time to specify carefully all details. However, Mantis obviously has some internal timeout for validity of the input forms, and when the user presses "Submit", the following error appears:

-----

APPLICATION ERROR #2800

Invalid form security token. This could be caused by a session timeout, or accidentally submitting the form twice.

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.

-----

This is very annoying since in many cases it leads to all the user input being lost (depends on a browser; e.g. Opera preserves input in most cases if returning by Back button).

I propose this timeout should be disabled. If it is really necessary for some purpose (apart of training the people not to be relaxed), the behavior should be changed so as to preserve user input and allow the user to re-submit the data (e.g. some pop-up notification can be provided).
TagsNo tags attached.
Test case number

Relationships

related to 0024638 closedbugmaster Bug tracker - if category is not checked than Submit Report would lead to lost input 

Activities

aiv

2013-06-21 12:56

reporter   ~0024833

As I see it, we should prolong this time interval to acceptable limits, for example 24h. I think this will be enough. This is because we can potentially get performance problems if we don't limit this timeout.
In any case there is no sense to set this limit to greater than 3 days, because it's a Mantis login session timeout.

aiv

2013-06-27 18:49

reporter   ~0024904

The session timeout parameter was set to 2 hours a week ago (after discussion with AKV). I think this covers over 95% of all such cases. It could be insecure to set this parameter to greater value.
Have you noticed the changes and what do you think is this enough?

abv

2013-07-12 07:09

manager   ~0025040

I deem 2 hours is still not sufficient, since it is usual situation when you can open a form to report an issue on one day but complete next day (it takes a while sometimes to get complete details of the problem to report it properly).

Hence I would propose 1 day as reasonable timeout.

On the other side, the real problem is not the value of the timeout, but the fact that all user input is lost when this happens. Thus I propose to work in this direction: instead of reloading the page, give a timeout message in separate field so that the form data are preserved. Or (I guess the easiest way) just include this timeout in Java script which would disable button "Submit" on the report page after the timeout, and show the same message below the button so that the user recognizes what happens.

ibs

2013-11-25 17:38

developer   ~0026894

Last edited: 2013-11-25 17:40

dear aiv,
a session timeout is often the cause of the lost a note. Is there any possibility to remove this timeout completely without its expanding?

This issue is very important and it would be great if any solution could be found...

aiv

2013-11-25 19:06

reporter   ~0026899

Last edited: 2013-11-26 11:17

I fully agree with you and I'm planning to implement some improvements that were sketched by abv. Initially scheduled for early next year, but I believe I'll try to do something next month.

The way when we changing session timeout - is a deadlock way. This is due to the fact that all session data will be collected on the server - without regular cleaning by garbage collector. I'm not saying exactly for Mantis, but I know that is sometimes very large amounts of data, and as a rule that is a waste data.

I want to add that it is known MantisBT issue, and there no complex solution at the moment:

http://www.mantisbt.org/docs/master-1.2.x/en/administration_guide.html#ADMIN.TROUBLESHOOTING.ERRORS.2800

Error 2800 - Invalid form security token

This error may only occur when Form Validation is enabled with $g_form_security_validation = ON. There are several known cases that could trigger it:

Multiple submissions of a form by clicking on the submit button several times (user error)

Invalid or unauthorized submission of a form, e.g. by hand-crafting the URL (CSRF attack)

Expired PHP session

In the first two instances, MantisBT's behavior is by design, and the response as expected. For expired sessions however, the user is impacted by system behavior, which could not only cause confusion, but also potential loss of submitted form data. What happens is driven by several php.ini configuration settings:
The ratio session.gc_probability divided by session.gc_divisor, which determines the probability that the garbage collection process will start when a session is initialized.

session.gc_maxlifetime which specifies (as the name does not indicate) the minimum validity of session data.

With PHP default values, sessions created more than 1440 seconds (24 minutes) ago have a 1% chance to be invalidated each time a new session is initialized. This explains the seemingly random occurence of this error.
Unfortunately, this problem cannot be fixed without a major rework of the way sessions and form security are handled in MantisBT.

As a workaround, the Administrator can

Increase the value of session.gc_maxlifetime

Set $g_form_security_validation = OFF. Note that for security reasons, it is strongly recommended not to do this.

Users may also install local tools to avoid loss of form data, e.g. Lazarus Form Recovery add-on for Firefox.
Further references and reading:

MantisBT issues 12381, 12492, 13106, 13246

ibs

2013-11-26 10:33

developer   ~0026903

aiv,

Thanks for the explanation :)

>The way when we changing session timeout - is a deadlock way. This is due to the fact that all session data will be collected on the server - without regular cleaning by garbage collector. I'm not saying exactly for Mantis, but I know that is sometimes very large amounts of data, and as a rule that is a waste data.

1. if there is enough space on a server maybe we expand timeout for awhile?
2. and of course try $g_form_security_validation = OFF (or are there obvious reasons not to do it?)

if anything will go wrong - we revert the changes.

What do you think?

ibs

2013-11-26 10:35

developer   ~0026904

aiv, and thank for 'Lazarus Form Recovery add-on for Firefox'

ibs

2014-01-14 11:05

developer   ~0027461

Last edited: 2014-01-14 11:06

dear aiv,
12381, 12492 and 13246 issues aren't found

and what kind of connection does 13106 issue have? :/

aiv

2014-01-14 11:24

reporter   ~0027463

I just cited part of MantisBT documentation, so these issues are from http://www.mantisbt.org/bugs/my_view_page.php
I remember this issue and I'll get down to this issue soon

ibs

2014-01-14 12:35

developer   ~0027470

aiv, thanks :)

aiv

2014-01-21 17:57

reporter   ~0027579

I have done some work in this direction:

1. As the common reason of 2800 error is session timeout (session files are cleaned on the server by garbage collector or session variables are passed away by any reason) the mechanism of session auto prolongation has been integrated. Each 10 minutes a page opened in a browser sends "keep alive" request to server, thus session files are updated on a server for current user. It could helps, but yet not always.
It was already integrated to tracker.dev.opencascade.org

2. Second direction is to prevent user from losing form data (if session has expired, or user tries to send form from page which was taken from browser cache or any other reason when we about to getting 2800 error).
For all forms that are protected by "form security token" (report page, add bug note etc.) a little bit of javascript code was added to handle the following:
* when submitting such form, javascript catches this operation; then server is asked: if "form security token" is valid?
* if "yes" (or request fails) then form is submitted as usual
* if "no" (this case exactly the same when be get 2800 error) then alert message appeared with the following text:
-----
Seems that form security token is not valid. This could be caused by a session timeout, or accidentally submitting the form twice.

It means that you lose your form data if you try to submit it. Please copy all important data from this form, then refresh page (Ctrl + F5) and try to send form again.
-----
Ok
-----

I have not integrated it to tracker.dev.opencascade.org, only to internal copy.

What do you think about this?

ibs

2014-01-21 18:06

developer   ~0027581

aiv,
great features! :)

I have a question: could this javascript store user's information, refresh page, insert stored information in refreshed page and then "click" on submit button?

abv

2014-01-22 09:10

manager   ~0027582

Sounds great! I could not reproduce the problematic situation, and suggest this change is introduced on the site and we see how it works.

aiv

2014-01-22 19:55

reporter   ~0027616

Second part of 24039#c27579 was integrated to tracker.dev.opencascade.org, please test.
Also, as a side effect, submit buttons are disabled after submitting such forms (previously it was worked only for "Add Note" button on "View Issue Details" page).

ibs,
Good question, I'll think in this direction. At least this script can exchange information between server and page, and I think it is possible to do something even without page refreshing (if it will secure enough).

ibs

2014-01-23 11:13

developer   ~0027624

aiv, it would be great!

aiv

2014-10-03 15:11

reporter   ~0032640

Ibs, please try it now.
A new layer of functionality that preserves the user input is provided for Bug Report form. I hope now will be quite difficult to lose the form data.

ibs

2014-10-23 12:21

developer   ~0033622

aiv, it works great! :)

Issue History

Date Modified Username Field Change
2013-06-21 09:28 abv New Issue
2013-06-21 09:28 abv Assigned To => aiv
2013-06-21 12:56 aiv Note Added: 0024833
2013-06-27 18:49 aiv Note Added: 0024904
2013-06-27 18:49 aiv Assigned To aiv => abv
2013-06-27 18:49 aiv Status new => feedback
2013-07-12 07:09 abv Note Added: 0025040
2013-07-12 07:09 abv Assigned To abv => aiv
2013-07-12 07:09 abv Status feedback => assigned
2013-11-25 17:38 ibs Note Added: 0026894
2013-11-25 17:38 ibs Status assigned => feedback
2013-11-25 17:40 ibs Note Edited: 0026894
2013-11-25 19:06 aiv Note Added: 0026899
2013-11-26 10:33 ibs Note Added: 0026903
2013-11-26 10:35 ibs Note Added: 0026904
2013-11-26 11:17 aiv Note Edited: 0026899
2014-01-14 11:05 ibs Note Added: 0027461
2014-01-14 11:06 ibs Note Edited: 0027461
2014-01-14 11:24 aiv Note Added: 0027463
2014-01-14 12:35 ibs Note Added: 0027470
2014-01-14 16:23 aiv Status feedback => assigned
2014-01-21 17:57 aiv Note Added: 0027579
2014-01-21 18:06 ibs Note Added: 0027581
2014-01-22 09:10 abv Note Added: 0027582
2014-01-22 19:55 aiv Note Added: 0027616
2014-01-23 11:13 ibs Note Added: 0027624
2014-10-03 13:36 aiv Relationship added related to 0024638
2014-10-03 15:11 aiv Note Added: 0032640
2014-10-03 15:11 aiv Assigned To aiv => ibs
2014-10-03 15:11 aiv Status assigned => resolved
2014-10-23 12:21 ibs Note Added: 0033622
2014-10-23 12:21 ibs Assigned To ibs => aiv
2014-10-23 12:21 ibs Status resolved => reviewed
2015-01-21 10:34 bugmaster Status reviewed => closed
2015-01-21 10:34 bugmaster Resolution open => fixed