mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 13:05:53 +03:00
[GH-ISSUE #98] Using anything but built in authentication causes users to lose their settings on a password change #81
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#81
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jasonmunro on GitHub (Jul 21, 2016).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/98
Originally assigned to: @jasonmunro on GitHub.
Persistent settings stored on the server are encrypted with a key derived from the user's clear text password. If that password changes, their settings are lost (unless using built in auth and the password is changed from inside Cypht). This might be a detectable situation, and we can then prompt the user for their old/new passwords after login to restore the settings.
@jasonmunro commented on GitHub (Jul 27, 2016):
This can be detected, and the user_config object now has a flag set on login that can be read by modules to determine if it's appropriate to prompt the user to recover their settings. To complete this solution, I'm going to create a module set that uses this flag and provides a "settings recovery" page. Users can enter their old and new passwords, and we will attempt to decrypt their settings with the old password, then re-encrypt the with the new one.
@jasonmunro commented on GitHub (Jul 31, 2016):
recover_settings module set is committed to the master branch