View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005655 | mantisbt | bugtracker | public | 2005-05-25 23:15 | 2005-07-23 02:10 |
Reporter | moldor | Assigned To | thraxisp | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.0.0a2 | ||||
Fixed in Version | 1.0.0rc1 | ||||
Summary | 0005655: Problems creating a new account (similar to 0005653) | ||||
Description | After trying to sign up on my own site and getting this bug, I got it on the bugs.mantisbt.org site as well. Error returned is; Sign up for a new account, click on the url in the confirmation email and get | ||||
Additional Information | Not only do you have to log out totally before clicking on the confirmation URL, but it appears you have to flush your cookies as well. If I opened the confirmation URL in another browser (like Galeon) it worked. | ||||
Tags | No tags attached. | ||||
Reminder sent to: masc Masc, what are your thoughts on this issue? |
|
Can you retest this in 1.0.0a3? Changes for another bug (0005653) will probably fix this one as well. |
|
I am getting this with 1.0.0a3 also. Reading the code, it looks like the html footer is touching 'last_visit' after it's been used to generate the confirm_hash in the password email, if it knows who is logged in. I just had success by having a new user clear cache and restart their browser, so maybe it is a cookie issue of some kind. BTW search on '1901' and you turn up three issues including this one. |
|
Do you allow anonymous logins on your site? |
|
No, we do not allow anonymous logins, if my reading of the config_inc files is correct. I believe this is the installation default and we didn't change it. Currently we are having people create accounts themselves, and then an admin gives them an appropriate access level after verifying they are someone we know. They run into problems fairly quickly, either before they can login the first time or shortly thereafter. We're not sure why some people see the problem and others don't, or why it fails at different stages for different people. The theories I had based on last_visit in the footer weren't as experimentally repeatable as I would have expected. We have had success by resetting people's passwords and telling them to clear cache & cookies before they click on the password URL they receive from mantis. We are using this as a workaround for now. |
|
The last visited timestamp causes these failures. With this change, it is not updated on the account_update.php page, where any errors would be detected and flagged. This allows the back function to work. Changes (mandatory) Changes (optional) |
|