View Issue Details

IDProjectCategoryView StatusLast Update
0011394mantisbtauthenticationpublic2010-04-23 14:30
ReporteratrolAssigned Todhx 
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Versiongit trunk 
Target Version1.2.1Fixed in Version1.2.0 
Summary0011394: Lost password not working, no message output, no mail
Description

when clicking "lost password" and entering a valid username and e-mail MantisBT returns to login page.

No e-mail is sent.

No message is displayed like in 1.1.x
Password Message Sent
If you supplied the correct username and e-mail address for your account, we will now have sent a confirmation message to that e-mail address. Once the message has been received, follow the instructions provided to change the password on your account.

Additional Information

nightly build from 14.01.2010
and in 1.2.0rc2

TagsNo tags attached.

Relationships

has duplicate 0011474 closeddhx Password reminder doesn't send email 
has duplicate 0011567 closeddhx "Lost Password" feature doesn't work 
has duplicate 0010628 closeddhx Lost Password feature does not send eMail 
related to 0011902 closedatrol Reset password and user notification mails are not sent 

Activities

rolfkleef

rolfkleef

2010-01-27 13:11

reporter   ~0024264

I just ran into the same problem on our 1.2.0rc2 installed version today

atrol

atrol

2010-02-01 14:40

developer   ~0024276

I think this one should have set "Target Version" to 1.2.x because standard functionality which was working in 1.1.x is broken.

watergad

watergad

2010-02-02 09:09

reporter   ~0024288

Last edited: 2010-02-02 09:09

View 2 revisions

Isn't it the core/email_api.php problem in the
function email_send_confirm_hash_url( $p_user_id, $p_confirm_hash )

line (#472 if I'm not wrong):
lang_push( user_pref_get_language( $p_user_id ) );

which doesn't work (maybe with certain languages, I'm not sure).

If so, try to comment this line (this works for me).

cor3huis

cor3huis

2010-02-04 07:15

reporter   ~0024312

"Target Version" to 1.2.0 IMHO indeed.

jurgenhaas

jurgenhaas

2010-02-05 15:25

reporter   ~0024334

Can confirm that commenting line #472 of core/email_api.php with lang_push( user_pref_get_language( $p_user_id ) ); solves the problem for now.

dhx

dhx

2010-02-07 20:12

reporter   ~0024342

Thanks for the bug report, and finding which line caused the issue. I should have fixed it now (in both 1.2.x and 1.3.x branches). I suspect this problem arises when a user language preference is incorrect or invalid in some way. Now it should fall back to the default language of the MantisBT installation when the user language preference is not correct.

dhx

dhx

2010-02-07 20:13

reporter   ~0024343

Please test this for me (as I couldn't reproduce the original issue) and reopen if the problem still remains. Thanks!

atrol

atrol

2010-02-08 09:33

developer   ~0024346

still not working
watergad wrote that he changed email_api.php
but email_api.php is not in the changeset
@dhx did you forget it, or was this only a workaround for the bugs you fixed in lang_api.php and user_pref_api.php ?

dhx

dhx

2010-02-08 10:48

reporter   ~0024348

Try adding these two lines to the bottom of config_inc.php to see if it makes a difference:

$g_send_reset_password = ON;
$g_enable_email_notifications = ON;

Also, password reset emails aren't sent for protected accounts.

atrol

atrol

2010-02-08 11:39

developer   ~0024349

This is a fresh test installation without any special configuration in config_inc.php

Content of config_inc.php:

$g_hostname = 'XXXXX';
$g_db_type = 'mysql';
$g_database_name = 'XXXXXX';
$g_db_username = 'XXXXXX';
$g_db_password = 'XXXXXX';

Am I right, that the values in config_defaults_inc.php are taken if there is no other configuration?
If yes, they are set as you requested.

I think this was a typo, I didn't find in source:
$g_enable_email_notifications should be
$g_enable_email_notification

My test users are not protected

Further hint:
After requesting the new password and getting no mail I logged in with the old password which still works.
Sometimes I get the following message, but can go on working without further problems.
APPLICATION ERROR #2800
Invalid form security token. Did you submit the form twice by accident?

If you want you can try my test installation to verify the behaviour (This is the latest nightly build from today, which contains your latest commits in GIT)
http://www.atrol.de/mantisbt-1.2.0rc2-2010-02-08

dhx

dhx

2010-02-09 23:19

reporter   ~0024356

I think the patch from 0010780 may fix this issue? We forgot to backport it to the 1.2.x branch which may explain why I couldn't reproduce this problem (I use the 1.3.x branch typically).

Please checkout the latest 1.2.x master branch from git.mantisbt.org and see if things are working again. I can confirm that with my setup, the lost password functionality is working fine on the latest version of 1.2.x.

atrol

atrol

2010-02-10 02:37

developer   ~0024358

I noticed this patch yesterday and tried already. But behaviour didn't change.
To be complere sure I will setup a fresh installation with the next nighly build of 1.2. First I will setup a 1.3 to find out whether we are looking for something which has to be backported or a still not fixed problem

atrol

atrol

2010-02-10 05:40

developer   ~0024362

Also not working with 1.3dev (where I had to tweak the new encryption code to get it run, but this is another story ...)

atrol

atrol

2010-02-11 10:46

developer   ~0024375

Have a look at 0011493
maybe this is related

jurgenhaas

jurgenhaas

2010-02-13 11:21

reporter   ~0024387

Same here. Just downloaded 1.2.x master from 13-2-2010 and the error is still there. When disabling

lang_push( user_pref_get_language( $p_user_id ) );

oin line 494 of core/email_api.php then all works fine. Also, the user I've tried that with has a proper language configured, so the note from the latest changeset doesn't apply here. The problem must be something else.

dhx

dhx

2010-03-02 07:36

reporter   ~0024589

Can someone please try reproducing this problem with the following error verbosity settings in config_inc.php:

   $g_show_detailed_errors = ON;
    $g_display_errors = array(E_WARNING => 'halt',
                               E_NOTICE => 'halt',
                               E_USER_ERROR => 'halt',
                               E_USER_WARNING => 'halt',
                               E_USER_NOTICE => 'halt',
                               E_ALL => 'halt');

This should hopefully provide more information on any errors that may be occurring.

Thanks

jurgenhaas

jurgenhaas

2010-03-02 08:24

reporter   ~0024591

I've tried it and what's strange: when using those settings and uncommenting lang_push( user_pref_get_language( $p_user_id ) ); in email_api.php, again no email is sent out :-( and no error message produced.

Cross tests performed:

When creating an error elsewhere, I get a very detailed error message, so that part works.

Commenting the line in email_api.php again, emails get sent out.

So, something in either user_pref_get_language() or in lang_push() must happen that avoids sending email but doesn't throw an error.

DominionSpy

DominionSpy

2010-03-16 10:20

reporter   ~0024768

Last edited: 2010-04-14 09:37

View 2 revisions

I still had this problem after using the changeset below, but I have now fixed it with a small change.

In user_pref_api.php, in the user_pref_get() function, there is a line (around line 480):

if ( auth_get_current_user_id() == $p_user_id ) {

I have changed this to:

if ( auth_is_user_authenticated() && auth_get_current_user_id() == $p_user_id ) {

The problem seems to be that if there is no logged in user (and there won't be for a password reset from the login screen), the auth_get_current_user_id() function will throw you back to the login screen immediately. Checking whether the user is actually logged in gets round this.

dhx

dhx

2010-04-21 08:53

reporter   ~0025190

Thanks DominionSpy, your changes are correct and I've applied them to the repository. Apologies with the delay in getting this fixed.

dhx

dhx

2010-04-21 08:54

reporter   ~0025191

If anyone still experiences problems with the latest git checkout of the 1.2.x or 1.3.x branches, please reopen this issue again.

Thanks

Related Changesets

MantisBT: master-1.2.x 5f7cef9d

2010-02-08 01:08:18

dhx

Details Diff
Fix 0011394: Lost password email not sent when user language is invalid

When the language specified in the preferences for a user does not exist
or is otherwise invalid (for example: when updating from previous
versions of MantisBT), the lost password email is not sent to the user.

This is probably because of lang_push( user_pref_get_language( user_id )
) where user_pref_get_language can return false and lang_push expects a
string (or null).
mod - core/lang_api.php Diff File
mod - core/user_pref_api.php Diff File

MantisBT: master c8e30df5

2010-02-08 01:08:18

dhx

Details Diff
Fix 0011394: Lost password email not sent when user language is invalid

When the language specified in the preferences for a user does not exist
or is otherwise invalid (for example: when updating from previous
versions of MantisBT), the lost password email is not sent to the user.

This is probably because of lang_push( user_pref_get_language( user_id )
) where user_pref_get_language can return false and lang_push expects a
string (or null).
mod - core/lang_api.php Diff File
mod - core/user_pref_api.php Diff File

MantisBT: master-1.2.x 1a1c9762

2010-04-21 12:43:34

dhx

Details Diff
Fix 0011394: No email sent for lost password process

When a MantisBT installation is setup without anonymous access enabled
auth_get_current_user_id() will fail, redirecting the user back to the
login screen.

This was due to a problem in user_pref_get() where it was assumed that a
user was logged in. For the lost password recovery step (with no
anonymous login), the lost password recovery step happens without any
user logged in.
mod - core/user_pref_api.php Diff File

MantisBT: master 2e73850a

2010-04-21 12:43:34

dhx

Details Diff
Fix 0011394: No email sent for lost password process

When a MantisBT installation is setup without anonymous access enabled
auth_get_current_user_id() will fail, redirecting the user back to the
login screen.

This was due to a problem in user_pref_get() where it was assumed that a
user was logged in. For the lost password recovery step (with no
anonymous login), the lost password recovery step happens without any
user logged in.
mod - core/user_pref_api.php Diff File

Issue History

Date Modified Username Field Change
2010-01-14 16:43 atrol New Issue
2010-01-27 13:11 rolfkleef Note Added: 0024264
2010-01-27 13:11 rolfkleef Status new => confirmed
2010-01-27 13:11 rolfkleef Category signup => authentication
2010-01-27 13:11 rolfkleef Additional Information Updated View Revisions
2010-02-01 14:40 atrol Note Added: 0024276
2010-02-02 09:09 watergad Note Added: 0024288
2010-02-02 09:09 watergad Note Edited: 0024288 View Revisions
2010-02-04 07:15 cor3huis Note Added: 0024312
2010-02-05 15:25 jurgenhaas Note Added: 0024334
2010-02-07 19:05 dhx Relationship added has duplicate 0011474
2010-02-07 20:07 dhx Assigned To => dhx
2010-02-07 20:07 dhx Status confirmed => assigned
2010-02-07 20:07 dhx Target Version => 1.2.2
2010-02-07 20:12 dhx Note Added: 0024342
2010-02-07 20:12 dhx Status assigned => resolved
2010-02-07 20:12 dhx Fixed in Version => 1.2.2
2010-02-07 20:12 dhx Resolution open => fixed
2010-02-07 20:13 dhx Note Added: 0024343
2010-02-07 20:20 dhx Changeset attached master-1.2.x 5f7cef9d =>
2010-02-07 20:20 dhx Changeset attached master c8e30df5 =>
2010-02-08 09:33 atrol Note Added: 0024346
2010-02-08 09:33 atrol Status resolved => feedback
2010-02-08 09:33 atrol Resolution fixed => reopened
2010-02-08 10:48 dhx Note Added: 0024348
2010-02-08 11:39 atrol Note Added: 0024349
2010-02-08 11:39 atrol Status feedback => assigned
2010-02-09 23:19 dhx Note Added: 0024356
2010-02-10 02:37 atrol Note Added: 0024358
2010-02-10 05:40 atrol Note Added: 0024362
2010-02-11 10:46 atrol Note Added: 0024375
2010-02-13 11:21 jurgenhaas Note Added: 0024387
2010-02-22 14:32 jreese Target Version 1.2.0 => 1.2.2
2010-02-26 09:19 atrol Relationship added has duplicate 0011567
2010-03-02 07:27 dhx Relationship added has duplicate 0010628
2010-03-02 07:36 dhx Note Added: 0024589
2010-03-02 08:24 jurgenhaas Note Added: 0024591
2010-03-16 10:20 DominionSpy Note Added: 0024768
2010-04-14 09:37 DominionSpy Note Edited: 0024768 View Revisions
2010-04-21 08:53 dhx Note Added: 0025190
2010-04-21 08:54 dhx Note Added: 0025191
2010-04-21 08:54 dhx Status assigned => resolved
2010-04-21 08:54 dhx Resolution reopened => fixed
2010-04-21 09:00 dhx Changeset attached MantisBT master-1.2.x 1a1c9762 =>
2010-04-21 09:00 dhx Changeset attached MantisBT master 2e73850a =>
2010-04-23 14:30 jreese Status resolved => closed
2010-05-10 21:35 dhx Relationship added related to 0011902