cypht icon indicating copy to clipboard operation
cypht copied to clipboard

Logging in after changing password leads to broken settings

Open HanPrower opened this issue 5 years ago • 8 comments

🐛 Bugreport

After changing account password with php ./scripts/update_password.php username password can't login without deleting cookies. Once logged in settings of account no longer seem to be attached.

Changing the password back to what it was before allows settings to load correctly.

I see no way to change the password internally.

Version & Environment

Commit: https://github.com/jasonmunro/cypht/commit/8f76381981376fc5b045c3bda37acaa3f434bf87 OS: Arch Linux (rolling) Auth: Database (mariadb) + Redis Environment:

PHP version	7.3.4
Zend version	3.3.4
SAPI	fpm-fcgi
Enabled Modules	core, pop3, imap, smtp, account, idle_timer, desktop_notifications, themes, nux, developer, history, saved_searches, advanced_search, profiles, inline_message, imap_folders, keyboard_shortcuts

Steps to reproduce

  1. Make account and set up some settings, save & logout
  2. Change password using php ./scripts/update_password.php username password (the password hash in the db does change)
  3. Try and login; prompted is wrong
  4. Delete cookies and login again; this time it logs in
  5. Notice any saved settings are missing (general, email servers, etc.)
  6. Use script to set password back to what it was, delete cookies and login and settings are back

I did see https://github.com/jasonmunro/cypht/issues/98, but it doesn't seem relevant to this.

HanPrower avatar Apr 26 '19 09:04 HanPrower

Hello, thanks for the feedback. A couple thoughts:

  • When using built in authentication you should have a Settings -> Password page in the main menu that allows you to change your password without losing your settings.
  • It's a known issue that changing your password externally from Cypht (including the cli script, which I sort of forgot about), causes settings to be lost. There is a recover_settings module set however that you can enable to recover those presuming the old password is still known.

We could also improve that cli script to take both the old and new password so that it can decrypt then re-encrypt settings so this does not happen when using it.

jasonmunro avatar May 06 '19 20:05 jasonmunro

Hm, not sure how I missed the Settings -> Password. I swear it wasn't there before... probably just blind.

When you do use that form, however, it does throw an error. When looking at the error log it seems related to a missing translation. The password does change though.

HanPrower avatar May 07 '19 08:05 HanPrower

We log missing translations as a way to easily know what needs to be added to the translation files, but those messages are information only and will not cause bad behavior (aside from not being translated properly).

jasonmunro avatar May 07 '19 14:05 jasonmunro

Lost settings reminds me of https://github.com/jasonmunro/cypht/issues/349

marclaporte avatar Feb 27 '21 00:02 marclaporte

Likely fixed by https://github.com/jasonmunro/cypht/commit/0eef1364503158b4ef7b058eda07ab7f9a4b63c5

marclaporte avatar Mar 09 '21 21:03 marclaporte

Likely fixed by 0eef136

unfortunately it will not effect that. The CLI script will need quite a bit more work to correctly maintain the settings on password change including the requirement that the old password be submitted as an argument

jasonmunro avatar Mar 09 '21 22:03 jasonmunro

I am going to keep this open as it is legit - however it is not a bug as I built this as a last resort for restoring login. We can address this over time (changing passwords in the app successfully converts settings for non-emergency situations) but not hold up new releases :)

jasonmunro avatar Mar 10 '21 02:03 jasonmunro