View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005522 | mantisbt | other | public | 2005-04-26 18:07 | 2005-07-23 02:15 |
Reporter | brianf | Assigned To | thraxisp | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.0.0a1 | ||||
Fixed in Version | 1.0.0rc1 | ||||
Summary | 0005522: Emailed activation codes are always incorrect | ||||
Description | Hello, I have a fresh install of mantis and am trying to create some accounts. If I create a new account, I get an email with an URL ending in: I get the message: The new user is in mantis_user_table as: Given that user details and the activation code, should I be able to login? Can anybody see what is wrong? Thanks, Brian. | ||||
Tags | No tags attached. | ||||
Can you retest this in 1.0.0a3? Changes for another bug (0005653) will probably fix this one as well. |
|
The issue still exists for me in a3. |
|
I get a similar behavior with a3 as well. In my case, I found that if a new user sets their password immediately, they are fine. But if they logout without setting a new password and use the password reset feature, then that URL triggers error 1901. Bottom line is, the html footer touches last_visit during a password reset and so the confirm_hash in the URL is already out of date by the time it gets used. |
|
I think that this is a procedural error, but the update in the page footer complicates matters. If one requests a new account, or resets the password, one expects that the first thing one will do is set the new password. You are suggesting that people try to do other things first, rather than setting their password. As currently implemented, they can use the system for a single browser session (until they quit the browser window and a cookie is lost) as if they were fully logged in. Once they touch another page, they have to request a lost password, since one was never set. Supressing the footer update on the verify page will ensure that the verify can be used again if there is an error. A clear warning to set the password on the account page is needed. We may be better off to prevent them from going to any other page until the password is set. |
|
Reminder sent to: masc, moldor, vboctor Note that this issue (0005522) is a duplicate of 0005655 and 0005827. |
|
Fix submitted to CVS to highlight that user should set password on verify. lang/strings_english.txt -> 1.261 |
|
I think that this is fixed now. Please re-open if you see it again. |
|