View Issue Details

WikiRelated ChangesetsJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0014260mantisbtauthenticationpublic2012-05-15 13:082017-11-27 08:51
Reporteraholcomb89 Assigned Todregad  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.10 
Target Version1.2.11Fixed in Version1.2.11 
Summary0014260: Unable to reset administrator passwords. APPLICATION ERROR #1901.
Description

We recently moved servers and updated Mantis from 1.2.4 to 1.2.10. After successfully installing Mantis and importing our old mysql database we immediately ran into issues when attempting to reset an administrator user's password. The user will get the email, however when they click the link they get the message

"APPLICATION ERROR #1901
The confirmation URL is invalid or has already been used. Please signup again."

They will then get the error "Your account may be disabled or blocked or the username/password you entered is incorrect." when trying to log into the account. Even though they were never able to successfully change their password.

This only happens with administrator users. We have followed the same password reset procedure with lower-level users and have been successful.

We are using:

PHP 5.1.6
MySQL 14.12
Apache 2.2.3

TagsNo tags attached.
Attached Files
1-disable.patch (662 bytes)    
diff --git a/manage_user_edit_page.php b/manage_user_edit_page.php
index c413328..ceacb8c 100644
--- a/manage_user_edit_page.php
+++ b/manage_user_edit_page.php
@@ -180,7 +180,8 @@

 <!-- RESET AND DELETE -->
 <?php
-	$t_reset = helper_call_custom_function( 'auth_can_change_password', array() );
+	$t_reset = $t_user['id'] != auth_get_current_user_id()
+		&& helper_call_custom_function( 'auth_can_change_password', array() );
 	$t_unlock = OFF != config_get( 'max_failed_login_count' ) && $t_user['failed_login_count'] > 0;
 	$t_delete = !( ( user_is_administrator( $t_user_id ) && ( user_count_level( config_get_global( 'admin_site_threshold' ) ) <= 1 ) ) );
1-disable.patch (662 bytes)   
2-redirect.patch (1,083 bytes)    
diff --git a/manage_user_edit_page.php b/manage_user_edit_page.php
index c413328..0209520 100644
--- a/manage_user_edit_page.php
+++ b/manage_user_edit_page.php
@@ -189,11 +189,22 @@
 <div class="border center">
 
 <!-- Reset/Unlock Button -->
-<?php if( $t_reset || $t_unlock ) { ?>
+<?php
+	if( $t_reset || $t_unlock ) {
+		# If resetting the user's own password, make the form redirect to My Account page
+		if( $t_reset && $t_user['id'] == auth_get_current_user_id() ) {
+?>
+	<form method="post" action="account_page.php">
+<?php
+		} else {
+?>
 	<form method="post" action="manage_user_reset.php">
-<?php echo form_security_field( 'manage_user_reset' ) ?>
+		<?php echo form_security_field( 'manage_user_reset' ) ?>
 		<input type="hidden" name="user_id" value="<?php echo $t_user['id'] ?>" />
-<?php if( $t_reset ) { ?>
+<?php
+		}
+		if( $t_reset ) {
+?>
 		<input type="submit" class="button" value="<?php echo lang_get( 'reset_password_button' ) ?>" />
 <?php } else { ?>
 		<input type="submit" class="button" value="<?php echo lang_get( 'account_unlock_button' ) ?>" />
2-redirect.patch (1,083 bytes)   

Relationships

Relationship GraphDependency Graph
related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 

Activities

dregad

dregad

2012-05-16 06:16

developer   ~0031845

I have tried to reproduce your problem locally with the steps below, but everything worked successfully.

Setup: all configs set as per config_defaults_inc.php

  • Login as administrator
  • Go to Manage / Manage Users, Select another administrator's account
  • Click Reset Password button
  • Get message "A confirmation request has been sent..."
  • Open e-mail and click on the hyperlink

I am not receiving the error 1901 - instead I get (as expected) the confirmation "Your account information has been verified."

Did you check that the link in the mail points to your upgraded mantis instance ?
aholcomb89

aholcomb89

2012-05-16 09:35

reporter   ~0031847

Yes, the link in the email points to the upgraded Mantis.

Try this:

  • Create a new administrator account (I called mine testadmin)
  • Setup a password for this account through the received email
  • Login as the new administrator
  • Go to Manage / Manage Users
  • Select the new administrator account (same as the one currently logged in as)
  • Click Reset Password, DO NOT LOG OUT
  • Click the link in the email, I receive the error

This is all done using one instance of the Google Chrome browser with a tab for Mantis and a tab for my email.
dregad

dregad

2012-05-16 10:12

developer   ~0031849

OK, I can reproduce it now - although this seems to be an overly complicated way of resetting one's own password - in that case I think you should simply go to "My Account" and enter a new password directly.

The error is likely due to the way the confirmation hash is generated.
dregad

dregad

2012-05-16 12:42

developer   ~0031850

The root cause is indeed the confirmation hash, which is built using the user's last_visit timestamp; this is reset every time a Mantis page is successfully loaded (i.e. when footer is displayed).

I can think of 2 possible solutions to this problem:

  1. disable the reset button when managing one's own profile
  2. redirect to the "My Account" page

See attached patches, please test and let me know your feedback and thoughts
dregad

dregad

2012-06-06 11:07

developer   ~0032029

Implemented solution 1
grangeway

grangeway

2013-04-05 17:57

reporter   ~0036275

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

Related Changesets

MantisBT: master f3420be2

2012-06-06 03:45

dregad


Details Diff		 Prevent admin locking themselves out when resetting own password

Prior to this, when an admin attempted to reset their own password from
manage_user_edit_page.php (with $g_send_reset_password = ON), they were
no longer able to login because the sent confirmation hash was not valid
anymore since the last_visit timestamp used to generate it is updated by
every successful loading of the page (footer).

This commit prevents such behavior by hiding the "Reset Password" button
for the current user in the manage user page. One's own password should
be changed in account_page.php (My Account).

Fixes 0014260		 Affected Issues
0014260
mod - manage_user_edit_page.php Diff File

MantisBT: master-1.2.x 0777b3bd

2012-06-06 03:45

dregad


Details Diff		 Prevent admin locking themselves out when resetting own password

Prior to this, when an admin attempted to reset their own password from
manage_user_edit_page.php (with $g_send_reset_password = ON), they were
no longer able to login because the sent confirmation hash was not valid
anymore since the last_visit timestamp used to generate it is updated by
every successful loading of the page (footer).

This commit prevents such behavior by hiding the "Reset Password" button
for the current user in the manage user page. One's own password should
be changed in account_page.php (My Account).

Fixes 0014260		 Affected Issues
0014260
mod - manage_user_edit_page.php Diff File