Password reset oddness with multiple projects config

In my case, problem with force_passwd_change.

If you use SessionStore, try this.
Delete row name=force_change_passwd from session_attribute table.
Set 'force_passwd_change = false' in trac.ini.

I am not using SessionStore?, as it is not checked in the plugin. I did however try to Set 'force_passwd_change = false' in trac.ini, but it did't work Here is what the account manager portion of the ini looks like:

[account-manager] account_changes_notify_addresses = force_passwd_change = true generated_password_length = 8 hash_method = HtDigestHashMethod? notify_actions = [] password_file = /var/trac/login/svn.passwd password_store = HtPasswdStore?

Try harder to provide readable input to help with fixing issues, please. A simple code block should be sufficent:

[account-manager]
account_changes_notify_addresses =
force_passwd_change = true
generated_password_length = 8
hash_method = HtDigestHashMethod
notify_actions = []
password_file = /var/trac/login/svn.passwd
password_store = HtPasswdStore

Could you redo testing with latest trunk code and update your error description respectively add another comment here, as your time permits?

Looking back at the published configuration section it doesn't make sense at all:

hash_method is meant to select the hash type for SessionStore while you use an Apache htfile store. The password_file doesn't match common naming conventions, but this is not a technical problem - but confusing. As a side-note: Hash type selection is supported meanwhile for HtPasswdStore too, just use the new htpasswd_hash_type option.

Did you share the file in all Trac environments? You didn't mention that. But I guess this is the reason, why the first environment pushes the new password to the common password file, but chocks for some reason on the forced password change, while you can just use the new password from the other environments, that have no way to know about the password reset - so will never require another change.

Conclusion: Forced password change in it's current form is not designed to work well in such a scenario, since the password reset information is tracked inside a single Trac environment and not shared like the authentication store itself. I'll keep this in mind when working on a solution for #816. Resetting the password only after next successful login could help here too.

Well, this is my qualified best guess in the absence of better information from the OP. I'm open to better explanations and other suggestions.

Anyone caring for a fix should checkout r10264 or later, since a totally different 'lost password' procedure has been implemented with this changeset.

(In [10393]) AccountManagerPlugin: Releasing version 0.3, pushing development to 0.4.

This new feature release finally propagates a number of solutions into an official release, after some time of testing with trunk, so explicitely closes #442, #816, #2966, #3989, #4160, #6821, #7111, #8534, #8549, #8663, #8813, #8892, #8925, #8936 and #8939.

Should have made this months ago, but felt so many pending issues were too bad for a new release. But it has been a tremendous ticket burndown since last year, so it's really worth considering an upgrade now. See fresh changelog for details.

(In [10395]) AccountManagerPlugin: Releasing version 0.3, pushing development to 0.4.

This new feature release finally propagates a number of solutions into an official release, after some time of testing with trunk, so explicitely closes #442, #816, #2966, #3989, #4160, #6821, #7111, #8534, #8549, #8663, #8813, #8892, #8925, #8936 and #8939.

Should have made this months ago, but felt so many pending issues were too bad for a new release. But it has been a tremendous ticket burndown since last year, so it's really worth considering an upgrade now. See fresh changelog for details.