View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0012871 | mantisbt | authentication | public | 2011-03-21 11:42 | 2012-11-01 07:45 |
Reporter | Mario Splivalo | Assigned To | dregad | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | unable to reproduce | ||
Platform | Linux | OS | Debian | OS Version | 5 |
Product Version | 1.2.4 | ||||
Summary | 0012871: Unable to request password reset - ERROR 2800 | ||||
Description | When I want to reset password, even for nonexistent user, after filling up the form and clicking on 'Submit' I get: APPLICATION ERROR #2800 | ||||
Steps To Reproduce | Go to lost_pwd_page.php | ||||
Tags | No tags attached. | ||||
Does the client have cookies enabled? Is the PHP session timeout (defined within php.ini) long enough (and working) between the time taken for the lost password page to be requested and when the form is submitted? |
|
Yeps, cookies are enabled. This is default debian apache/php installation. From the time my browser rendered lost_pwd_page.php script and the time I pressed 'submit' there is maximum 10 seconds. |
|
As the notes in 0013082 state, the problem might be related to the usage of IE. I had one user that is using IE8, that had this problem. The error occured on Mantis 1.2.5 with PHP 5.2.11. Deleting cookies and cache helped for her. |
|
Ok, it seems that deleting cookies and clearing cache did not help. The problems occurs with IE and with Firefox. What makes it even worse, is, that she gets the same error when trying to login normally. Does anybody have an idea for me what to do? |
|
Some feedback for this: the user connected to Mantis with a wrong URL (e.g. IP/mantis instead of IP/Mantis). According to issue 0012438 I redirected these and other misspellings to the correct URL. After correcting the URL for the user to IP/Mantis, everything seems to work fine. Unfortunately, I don't know if this is the only user that used an incorrect URL, as the server is redirecting as described. So I can't really determine if there is a connection between these two issues. |
|
I was not able to reproduce this issue, including on IE8. Did you try increasing session.gc_maxlifetime ? Is php session / garbage collection working properly ? |
|