Modify

Opened 6 years ago

Closed 3 years ago

Last modified 3 years ago

#4160 closed defect (fixed)

Password reset oddness with multiple projects config

Reported by: mtavakoli@… Owned by: hasienda
Priority: normal Component: AccountManagerPlugin
Severity: major Keywords: needinfo multi-projects configuration
Cc: Trac Release: 0.11

Description

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.

Attachments (0)

Change History (8)

comment:1 Changed 6 years ago by 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.

comment:2 Changed 6 years ago by 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

comment:3 Changed 4 years ago by hasienda

  • Keywords multi-projects configuration added
  • Summary changed from Forgot My Password Issue to Password reset oddness with multiple projects config

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

comment:4 Changed 4 years ago by hasienda

  • Keywords needinfo added
  • Owner changed from pacopablo to hasienda

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

comment:5 Changed 3 years ago by hasienda

  • Priority changed from high to normal
  • Status changed from new to assigned

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.

comment:6 Changed 3 years ago by hasienda

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

comment:7 Changed 3 years ago by hasienda

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:8 Changed 3 years ago by hasienda

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

Add Comment

Modify Ticket

Action
as closed The owner will remain hasienda.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.