Bug #1129
access plaintext user password from model file
| Status: | Resolved | Start date: | 04/16/2013 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | lee | % Done: | 0% | |
| Category: | - | Spent time: | - | |
| Target version: | OSTN - Phase II - Stage 2 | |||
| Component: |
Description
unintended consequences! Like any good authentication framework, devise doesn't store plaintext passwords. But I need the plaintext password in two places, first devise needs it to encrypt the password and save it to the user model. second kamailio needs it to built the ha1 hash. But by the time a new user model is created, there isn't enough information to build a proper hash.
First, the model is created before a sip_username is saved. Since the ha1 hash is generated by a before_create callback, we are assured of the absence of the sip_username, by design. We also don't have access to the plaintext password at this time since the callback is in the model.
Perhaps I can store the plaintext password in an associated object until the sip_username attributed is updated to non-empty. use an after_update callback. This could also be preceded by some validations that all the required attributes are present to make the hash.
History
#1 Updated by lee almost 5 years ago
On second thought, a new User object CANNOT BE SAVED until all three components of the ha1 hash are present. This includes sip_username, password (plaintext) and domain. The plaintext password will persist in the object only until it is saved. There must be three validations to ensure these three pieces are entered and confirmed by the user before the object can be saved.
This'll be a lot of work but oh well. To scale it to multiple app servers will require some kind of object cache for new User objects that have not yet been saved. This is only relevant for the creation of user objects. Updates mean all validations have passed.
#2 Updated by lee almost 5 years ago
- Status changed from In Progress to Resolved
- Target version set to Phase II - Stage 2
done in master branch! User model is not saved until it is valid and the user is progressively prompted to continue through a multi stage transaction to make a valid model. A before_save callback is set to generate the correct hash values for the Kamailio authentication.