Password reset oddness with multiple projects config

[mtavakoli@…]

I have tried to use Forgot your password, to reset my accounts password. The Trac will successfully send me a new password that I can use to login. However, the password will not work for the particular project, from which within within I have requested "forgot my password".

Let's say I have threeprojects.

trac.whatever.com/project1 trac.whatever.com/project2 trac.whatever.com/project3

If I have my password reset through the first project by going to trac.whatever.com/project1/reset_password ,then my account will only work from that point on with the new reset password on projects 2 and 3, but not 1 anymore.

Any Ideas?

Thanks.

[anonymous]

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.

[mtavakoli@…]

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

[Steffen Hoffmann]

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

[Steffen Hoffmann]

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

[Steffen Hoffmann]

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.

[Steffen Hoffmann]

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

[Steffen Hoffmann]

(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.

[Steffen Hoffmann]

(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.