View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012381||mantisbt||sub-projects||public||2010-09-21 05:52||2012-11-01 07:45|
|Status||closed||Resolution||no change required|
|Platform||Windows XP SP3|
|Summary||0012381: APPLICATION ERROR #2800|
APPLICATION ERROR #2800
I have this in my php.ini file:
But that doesn't help.
What should I do?
|Tags||No tags attached.|
|duplicate of||0011680||closed||dhx||Mantis APPLICATION ERROR #2800 for Mantis 1.2.0|
|has duplicate||0013082||closed||dregad||Application 2800 Error When Reporting Issues|
|has duplicate||0014891||closed||dregad||Problem with large notes, the session expirated?|
|related to||0013106||closed||dregad||A lot of "APPLICATION ERROR #2800" when adding bug|
|related to||0013246||closed||dregad||APPLICATION ERROR #2800 when submitting notes|
|related to||0012871||closed||dregad||Unable to request password reset - ERROR 2800|
Same error with Firefox 3.6.10
Remember my login in this browser: unchecked
Any other place to look at?
There are multiple possible problems relating to proxy servers. Either you are using a proxy server with multiple exit nodes which invalidates the user session, or your proxy server is incorrectly caching form pages, including the unique CSRF tokens. If either of those are the issue, and you cannot solve the root problem, then you can disable form security tokens via the configuration option $g_form_security_validaton = OFF;
We were having this problem and the change fixed it. We would like to put the change back, due to the security risk. However, the only PC that had this problem was one using IE8. Firefox, Chrome, and older IE versions seemed fine. NOTE: It was also fixed by doing a refresh (CTRL-Refresh or SHIFT-Refresh) on IE8 before entering form data.
Yes, your suggestion with $g_form_security_validaton = OFF; helped in my situation. While I don't have a lot of hackers going to my site - probably that could work for now.
I am seeing the same behavior as in 0012381:0027069. But it also occurs on IE8 in compatibility code.
What are the risks of $g_form_security_validaton = OFF; ?
It's very risky disabling CSRF protection. See http://en.wikipedia.org/wiki/Cross-site_request_forgery for details on how it works.
I can understand that, but then my question is if this issue is already recognized and if there is a solution. Because niw we have to made the trade-off between security ( which was not present in older versions ) and usability for the users.
Strange thing is that it seems browser-related ( IE ).
I notice a lot of comments on the this bugtracker, the MantisBT forum and on the internet regarding this issue for quit some time, but do not find a solution.
Is anyone able to help?
Unassigned from jreese as he is no longer actively developing.
With error 2800, the problem is most likely caused by php session settings.
As pages tends to remain open for a while before user eventually decides to type something, by the time they click the submit button the session has expired. If the garbage collector has removed the session data when the form is submitted, then the http form's security token (CSRF protection) is no longer valid.
Recommendation is to increase session.gc_maxlifetime as appropriate (in the office I have it set to 8 hrs, so it's valid for a normal work day).