I have the AR class model (User) which has username and password. This model is also mapped to tbl_user table.
I decided to save the password after encryption (sha1), and I have a problem with the update operation among CRUD.
It bothers me because the encrypted password(quite long) is reloaded, and is being attempted to update. Although I removed the password fields from _form.php(view file), it still tries to save. If I didn’t change the password, it wouldn’t have to be changed.
Do I have to use querybuilder or something else? AR can’t be a solution?
replace the save() call in the update action to update() and specify the fields you want updated i.e. update(‘username’,‘change_date’) then the generated query will not touch the password field.
My application’s requirements are a person authorized to manage the user accounts is the only one to assign the passwords to users. This is a manager creating employee accounts. I didn’t have the need to validate the password with a second “password repeated” field.
I removed the password field from the _form.php file and added a new field password_new to the _form.php and the user class. I added the following code to the user class file (user.php):
class User extends CActiveRecord {
public $password_new;
...
public function rules() {
return array(
array('username, password', 'required'),
array('password_new', 'safe'),
array('password_new, password', 'length', 'min' => 5, 'max' => 40),
);
}
...
protected function beforeValidate() {
// If this is a new record, populate the password model attribute with the password_new
// value from the form.
if ($this->isNewRecord)
$this->password = $this->password_new;
return parent::beforeValidate();
}
/**
* Perform one-way encryption on the password before we store it in the database
*
*/
protected function afterValidate() {
parent::afterValidate();
// if the password_new form field was filled in, encrypt the new password
// and save in the password model attribute to be saved. If the new password
// was NOT entered, the hashed or encrypted password is still
// saved in the password attribute
if (!empty($this->password_new))
$this->password = $this->encrypt($this->password_new);
}
Upon the creation of a new user record, the beforeValidate function will populate $this->password with the new password. If and only if a new password is entered will $this->password be encrypted.
I’m having trouble with this and having trouble sorting it out. On an update (not a new record) I can see my new hashed password is written to the database. If I return to the update form, however, the password_new field is populated with the ORIGINAL password, so that if I again save the form, the record is updated in the database with the ORIGINAL password.
So… somehow it seems the value in $password_new is being retained… and I haven’t been able to find the right place to do something like $this->password_new = ‘’
It would be helpful if you could post some of your User class and UserController code. Can you post the actionUpdate and actionView from your UserController?
This is pretty embarrassing, but I’m going to describe the problem and solution in case anyone else has the same problem: I use Firefox and let it store my passwords. In order to make testing go more rapidly, I had allowed it to save my login usernames and passwords for some test users I created. For some reason, Firefox seemed to think the password_new field was the same as the password field in my login form… so on my update page it was filling in the password_new field with the password stored in Firefox.
I couldn’t for the life of me figure out why the password field was being populated when I loaded the update page… and that was why. When I deleted the testing site’s username and passwords in Firefox, the password_new field was empty as it should have been all along and the problem was solved.
Two things learned: 1) don’t let Firefox save passwords during test and 2) if you do let Firefox save passwords so it can autofill them, keep in mind that Firefox may make incorrect assumptions about what fields to autofill: it was autofilling a password field with a completely different id and name, only because the base URL was the same.
