Provide confirmation when password is changed

[Ryan J Ollos]

I vaguely remember discussing this issue, but perhaps I'm thinking of a different issue since I can't find a ticket for the item. There is a nice confirmation following a password reset when the user is forced to reset their password:

However, there is no confirmation when the user changes their password at will.

It would be nice to use add_notice to provide the user feedback that their password has been successfully changed.

Well, maybe it is implied and unnecessary to have the notice since the user is immediately logged out and forced to log back in with their new password, but the lack of a notice just seems a bit unsettling since they are so commonplace in Trac.

[Steffen Hoffmann]

Replying to rjollos:

I vaguely remember discussing this issue, but perhaps I'm thinking of a different issue since I can't find a ticket for the item. There is a nice confirmation following a password reset when the user is forced to reset their password:
...

Hm, I don't remember that.

However, there is no confirmation when the user changes their password at will.
...
It would be nice to use add_notice to provide the user feedback that their password has been successfully changed.
...

Sure, similar to what is already done inside the admin web-UI now.

Well, maybe it is implied and unnecessary to have the notice since the user is immediately logged out and forced to log back in with their new password, but the lack of a notice just seems a bit unsettling since they are so commonplace in Trac.

No, the behavior you describe here is actually strange, because no log-out should happen. I'll have to talk to you about that some more. Only thing, that makes me wonder, is the authentication store you use, that may interfere here somehow.

[Steffen Hoffmann]

Replying to hasienda:

Replying to rjollos:

Well, maybe it is implied and unnecessary to have the notice since the user is immediately logged out and forced to log back in with their new password, but the lack of a notice just seems a bit unsettling since they are so commonplace in Trac.

No, the behavior you describe here is actually strange, because no log-out should happen. I'll have to talk to you about that some more. Only thing, that makes me wonder, is the authentication store you use, that may interfere here somehow.

Could you re-check that particular behavior with recent changes for #10681 applied, please?

[Ryan J Ollos]

Yeah, I can test this weekend and get back to you. Thanks for pushing the changes!

[Ryan J Ollos]

Replying to hasienda:

Could you re-check that particular behavior with recent changes for #10681 applied, please?

I'm running the latest r12507 on my production server. I'm using HtPasswdStore (all enabled components are shown below).

What I see now is - after changing the password the user remains on the /prefs/account page. However, as soon as the user tries to navigate elsewhere, or refreshes the page, the authentication dialog appears forcing the user to enter their new password. Well, the behavior of page refresh is a little strange, as it suffers from the problem reported in #10752.

I think the current behavior is good, that the user should be forced to re-authenticate with their new password. Previously, I think I was seeing an authentication prompt immediately after submitting Save changes.

acct_mgr.admin.accountmanageradminpanel = enabled
acct_mgr.api.accountmanager = enabled
acct_mgr.guard.accountguard = enabled
acct_mgr.htfile.htpasswdstore = enabled
acct_mgr.macros.accountmanagerwikimacros = enabled
acct_mgr.notification.accountchangelistener = enabled
acct_mgr.notification.accountchangenotificationadminpanel = enabled
acct_mgr.pwhash.htpasswdhashmethod = enabled
acct_mgr.register.basiccheck = enabled
acct_mgr.register.usernamepermcheck = enabled
acct_mgr.web_ui.accountmodule = enabled
acct_mgr.web_ui.loginmodule = enabled
acct_mgr.web_ui.resetpwstore = enabled

[Steffen Hoffmann]

Replying to rjollos:

Replying to hasienda:

Could you re-check that particular behavior with recent changes for #10681 applied, please?

I'm running the latest r12507 on my production server. I'm using HtPasswdStore (all enabled components are shown below).

What I see now is - after changing the password the user remains on the /prefs/account page. However, as soon as the user tries to navigate elsewhere, or refreshes the page, the authentication dialog appears forcing the user to enter their new password. Well, the behavior of page refresh is a little strange, as it suffers from the problem reported in #10752.

I think the current behavior is good, that the user should be forced to re-authenticate with their new password. Previously, I think I was seeing an authentication prompt immediately after submitting Save changes.

Well, glad you like the behavior, but I'm still surprised, because it shouldn't work like that. The user remains on the /prefs/account page - ok. But I can't see how/why the re-authentication is triggered in your configuration. It was certainly not intended to re-authenticate. What special circumstances could invalidate the session for you? I'm able to change my password multiple times without loosing the current, authenticated session with authentication based on a no longer existing password.

While I'd like to clarify that, the other question is, obviously you would like to have session invalidation happen after password change, wouldn't you? This could be achieved by just re-directing to '/logout', right?

[Steffen Hoffmann]

Replying to rjollos:

However, there is no confirmation when the user changes their password at will.

In fact, there is one. See "Password successfully updated." right above 'Change password' in your screenshot? Seems just like the expected highlighting/green notification is gone. I'll investigate about the styling and history of possibly related changes.

[Ryan J Ollos]

Ah, good catch. It seems like that notification could be dropped, or merged with the div#notice that has the system-message class.

[Steffen Hoffmann]

(In [12672]) AccountManagerPlugin: Move more feedback to standard chrome messages, refs #10680.

Templates are modified and cleaned accordingly too - a nice simplification. Accompanied by another run on replacing ambiguous 'user' with 'username', once started back in [10288], but hopefully with no fix-ups this time.

[Steffen Hoffmann]

In 14363:

AccountManagerPlugin: Correct passwd reset notification msg body, refs #11867.

Thanks to alexkiro for reporting and proposing the change.

On review of this too long delayed patch I've seen other changes done but missing an entry in the changelog - fixed now as well, refs #10680 and #12097.