View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0024039 | Open CASCADE | Website:Tracker | public | 2013-06-21 09:28 | 2015-01-21 10:34 |
Reporter | Assigned To | ||||
Priority | high | Severity | major | ||
Status | closed | Resolution | fixed | ||
Summary | 0024039: Mantis session timeout and error "Invalid form security token" | ||||
Description | Registering 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). | ||||
Tags | No tags attached. | ||||
Test case number | |||||
|
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. |
|
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? |
|
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. |
|
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... |
|
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 |
|
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? |
|
aiv, and thank for 'Lazarus Form Recovery add-on for Firefox' |
|
dear aiv, 12381, 12492 and 13246 issues aren't found and what kind of connection does 13106 issue have? :/ |
|
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 |
|
aiv, thanks :) |
|
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? |
|
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? |
|
Sounds great! I could not reproduce the problematic situation, and suggest this change is introduced on the site and we see how it works. |
|
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). |
|
aiv, it would be great! |
|
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. |
|
aiv, it works great! :) |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-06-21 09:28 |
|
New Issue | |
2013-06-21 09:28 |
|
Assigned To | => aiv |
2013-06-21 12:56 |
|
Note Added: 0024833 | |
2013-06-27 18:49 |
|
Note Added: 0024904 | |
2013-06-27 18:49 |
|
Assigned To | aiv => abv |
2013-06-27 18:49 |
|
Status | new => feedback |
2013-07-12 07:09 |
|
Note Added: 0025040 | |
2013-07-12 07:09 |
|
Assigned To | abv => aiv |
2013-07-12 07:09 |
|
Status | feedback => assigned |
2013-11-25 17:38 |
|
Note Added: 0026894 | |
2013-11-25 17:38 |
|
Status | assigned => feedback |
2013-11-25 17:40 |
|
Note Edited: 0026894 | |
2013-11-25 19:06 |
|
Note Added: 0026899 | |
2013-11-26 10:33 |
|
Note Added: 0026903 | |
2013-11-26 10:35 |
|
Note Added: 0026904 | |
2013-11-26 11:17 |
|
Note Edited: 0026899 | |
2014-01-14 11:05 |
|
Note Added: 0027461 | |
2014-01-14 11:06 |
|
Note Edited: 0027461 | |
2014-01-14 11:24 |
|
Note Added: 0027463 | |
2014-01-14 12:35 |
|
Note Added: 0027470 | |
2014-01-14 16:23 |
|
Status | feedback => assigned |
2014-01-21 17:57 |
|
Note Added: 0027579 | |
2014-01-21 18:06 |
|
Note Added: 0027581 | |
2014-01-22 09:10 |
|
Note Added: 0027582 | |
2014-01-22 19:55 |
|
Note Added: 0027616 | |
2014-01-23 11:13 |
|
Note Added: 0027624 | |
2014-10-03 13:36 |
|
Relationship added | related to 0024638 |
2014-10-03 15:11 |
|
Note Added: 0032640 | |
2014-10-03 15:11 |
|
Assigned To | aiv => ibs |
2014-10-03 15:11 |
|
Status | assigned => resolved |
2014-10-23 12:21 |
|
Note Added: 0033622 | |
2014-10-23 12:21 |
|
Assigned To | ibs => aiv |
2014-10-23 12:21 |
|
Status | resolved => reviewed |
2015-01-21 10:34 | bugmaster | Status | reviewed => closed |
2015-01-21 10:34 | bugmaster | Resolution | open => fixed |