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)
core/html_api.php -> 1.176
core/utility_api.php -> 1.20

Changes (optional)
account_page.php -> 1.51
core.php -> 1.46