View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0013082||mantisbt||bugtracker||public||2011-06-14 17:45||2012-11-01 07:45|
|Summary||0013082: Application 2800 Error When Reporting Issues|
We have been receiving Application Error 2800 errors when reporting issues in Mantis 1.1.6 using IE7 and IE8. No issues when using FireFox. I have upgraded the software to 1.2.5 and the problem still persists for IE7 and IE8.
We are not behind a proxy and our PHP setting for session.gc_maxlifetime is 1440. In the 1.2.5 install, I am able to set the $g_form_validation_security to OFF and it resolves the issue.
Am I to conclude that there is not support for IE7 or IE8 for Mantis when reporting issues?
All tickets and forums posts point to a proxy caching issue, but we are not behind one. There is nothing in the documentation concerning this. Does it have anything to do with a difference in PHP versions? Is there a bug that describes my problem that has yet to be fixed that I should follow?
|Tags||No tags attached.|
I have installations of versions 1.1.x and 1.2.x which are running fine also for IE users (6,7,8)
Which PHP version do you use?
Try the following steps:
We are seeing the same thing with 1.2.5 (also saw it in 1.2.4)
Our PHP version is 5.2.17
I will try the steps on my development system, but that doesn't seem like a permanent solution. I don't want to have to keep doing this with our dozens of computers. To clear the mantis_tokens_table, I clean out PHP\sessions folder?
Oh, nevermind. That's in the database. Sorry :-D
We previously were using PHP 5.2.8 and Mantis 1.1.6 without any issues. We had to rebuild the server and so we are now using PHP 5.2.13 and Mantis 1.1.6. This setup is the one that is having an issue with IE7 and IE8. Upgrading Mantis from 1.1.6 to 1.2.5 didn't fix this issue. So I have submitted this ticket to try and get some clarification on the problem and if it can be resolved.
On my test system which is using PHP 5.2.13 and Mantis 1.2.5, I have cleared the cache, cookies and deleted the rows from the mantis_tokens table without any success in the Application 2800 error.
What versions are you using scaranol and atrol?
There is one session related fix in PHP version 5.2.14 :
Did you check session.save_path in php.ini and write access for the directory?
The default RPM install has setup this directory with the correct permissions. We have not modified this PHP setting at all and sessions are being stored in the directory.
Our PHP version is 5.2.17 and Mantis is at 1.2.5
I think I my have pinpointed our problem. Many of the computers go through Vyatta NAT router. It also has Squid built into it that does URL filtering, but also is probably acting like a proxy. The problem is I know for a fact we weren't having any issues with this in earlier versions. We were at Mantis 1.1.8 for a long time. I'm going to go backwards every version until I pinpoint where it seems to work without the $g_form_security_validation var being set to off.
Looks like the problem occurs in 1.2.0 and up.
I can't recreate this problem with 1.1.8
So you can report multiple issues using PHP 5.2.17 and a Mantis with version 1.1.8 or less using IE7 and 8?
I didn't try IE7, but I was able to report multiple issues with IE8 and had no problems.
Correct, PHP is at 5.2.17 still
|2011-06-14 17:45||jmaas||New Issue|
|2011-06-15 02:05||atrol||Note Added: 0028998|
|2011-06-15 02:10||atrol||Relationship added||related to 0012871|
|2011-06-15 02:10||atrol||Relationship added||related to 0012381|
|2011-06-15 02:11||atrol||Relationship added||related to 0011023|
|2011-06-15 08:18||scaranol||Note Added: 0029000|
|2011-06-15 08:25||scaranol||Note Added: 0029001|
|2011-06-15 11:25||jmaas||Note Added: 0029008|
|2011-06-15 11:45||atrol||Note Added: 0029009|
|2011-06-15 11:56||jmaas||Note Added: 0029010|
|2011-06-15 12:32||scaranol||Note Added: 0029011|
|2011-06-15 14:40||scaranol||Note Added: 0029012|
|2011-06-15 16:11||jmaas||Note Added: 0029013|
|2011-06-15 16:17||scaranol||Note Added: 0029014|
|2012-10-19 05:12||dregad||Relationship replaced||duplicate of 0012381|
|2012-10-19 05:12||dregad||Status||new => resolved|
|2012-10-19 05:12||dregad||Resolution||open => duplicate|
|2012-10-19 05:12||dregad||Assigned To||=> dregad|
|2012-11-01 07:45||atrol||Status||resolved => closed|