cypht
cypht copied to clipboard
Logging in after changing password leads to broken settings
🐛 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
- Make account and set up some settings, save & logout
- Change password using
php ./scripts/update_password.php username password
(the password hash in the db does change) - Try and login; prompted is wrong
- Delete cookies and login again; this time it logs in
- Notice any saved settings are missing (general, email servers, etc.)
- 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.
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.
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.
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).
Lost settings reminds me of https://github.com/jasonmunro/cypht/issues/349
Likely fixed by https://github.com/jasonmunro/cypht/commit/0eef1364503158b4ef7b058eda07ab7f9a4b63c5
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
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 :)