View Issue Details

IDProjectCategoryView StatusLast Update
0005522mantisbtotherpublic2005-07-23 02:15
Reporterbrianf Assigned Tothraxisp  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.0.0a1 
Fixed in Version1.0.0rc1 
Summary0005522: 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:
verify.php?id=7&confirm_hash=bae2ae3b5de41057524b5ceffde89df5

I get the message:
APPLICATION ERROR #1901
The confirmation URL is invalid or has already been used. Please signup again.

The new user is in mantis_user_table as:
"7";"testuser";"Test User";"testuser@sindar.net";"decdc346b6ef10893dd223410c598991";"2005-04-26 14:53:28";"2005-04-26 14:54:10";"1";"0";"25";"1";"0";"0";"42634c2da423c086c5860b4063b397e1d2ba3a215e1e198f9de9d04958bb9dce"

Given that user details and the activation code, should I be able to login?

Can anybody see what is wrong?

Thanks,

Brian.

TagsNo tags attached.

Relationships

related to 0005653 closedmasc Account signup confirmation 
has duplicate 0005827 closedthraxisp Account confirmation 
has duplicate 0005655 closedthraxisp Problems creating a new account (similar to 0005653
child of 0005460 closedvboctor Critical Issues to Fix for Mantis 1.0.0 Release 

Activities

thraxisp

thraxisp

2005-06-17 16:02

reporter   ~0010562

Can you retest this in 1.0.0a3? Changes for another bug (0005653) will probably fix this one as well.

rainwater

rainwater

2005-06-22 14:24

reporter   ~0010610

The issue still exists for me in a3.

toddpw

toddpw

2005-06-29 02:55

reporter   ~0010638

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.

thraxisp

thraxisp

2005-07-10 11:29

reporter   ~0010702

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.

thraxisp

thraxisp

2005-07-10 11:32

reporter   ~0010703

Reminder sent to: masc, moldor, vboctor

Note that this issue (0005522) is a duplicate of 0005655 and 0005827.

thraxisp

thraxisp

2005-07-11 15:10

reporter   ~0010717

Fix submitted to CVS to highlight that user should set password on verify.

lang/strings_english.txt -> 1.261
core/html_api.php -> 1.174
verify.php -> 1.6
account_page.php -> 1.50

thraxisp

thraxisp

2005-07-14 18:37

reporter   ~0010781

I think that this is fixed now. Please re-open if you see it again.