| sfGuardPlugin and propel-build-all-load [message #35529] |
Thu, 13 September 2007 20:26  |
 sivetic
Messages: 1
Registered: September 2007 |
Junior Member |
|
|
I have an issue with sfGuardPlugin and the way it handles the passwords when you execute a propel-load-data. What I did is run a propel-dump-data, which generated the dump file. I then took the dump file, split it up into the yml files for the tables, including a file with the two pertinent sfGuardPlugin tables. The file looks like this (other user info is removed):
sfGuardUser:
sfGuardUser_2:
username: sasa
algorithm: sha1
salt: 90a6d799dfe05bd56d61c8e68fd8c7dc
password: ce7fe25a81e1679ab6d18dbe35863ccf0b6b1e1d
created_at: 2007-09-07 13:02:57
last_login: 2007-09-13 08:44:09
is_active: 1
is_super_admin: 0
sfGuardUserProfile:
sfGuardUserProfile_1:
guard_user_id: sfGuardUser_2
first_name: Sasa
last_name: I.
email:
address:
city:
country:
phone_number:
is_owner: 0
created_at: 2007-07-04 12:17:12
updated_at: 2007-07-04 12:17:12
I then ran symfony propel-build-all-load frontend. It built the schema fine and populated the db from the fixtures. The only problem was that I could not log in with my original password any more.
After digging around a bit, what I've found is that sfGuardPlugin will take the password listed in the yml file (under the sfGuardUser class), and the corresponding salt for that password, and it will encode it before putting it into the database. Unfortunately, that password has already been encoded, and therefore the original password is changed now. I've tested this theory by removing the password and replacing it with my password in plain text, then running propel-load-data again, and that allowed me to log in. I've also tried to log in with the 'encoded' password from the yml file (i.e. ce7fe25a81e1679ab6d18dbe35863ccf0b6b1e1d) and that works as well.
I've checked the sfGuardUser.php file (found in sfGuardPlugin/lib/model directory), and the setPassword() function acts exactly as I thought it would - it takes the password passed to it, encodes it, and throws it in the DB.
Is there any way to avoid this behaviour? I understand why it happens, and I've had a very similar issue with a class of my own. It would however be nice to be able to avoid it so that propel-load-data can be used properly.
|
|
|
| Re: sfGuardPlugin and propel-build-all-load [message #52394 is a reply to message #35529 ] |
Wed, 21 May 2008 10:24  |
guglielmo.celata
Messages: 6
Registered: February 2008 |
Junior Member |
|
|
Hi sivetic,
I am having the very same problem right now.
I think one solution could be to add a modified setPassword method in the sfGuardPlugin/lib/model/sfGuardUser.php file.
It should check what you are doing:
- if you are loading data from a fixture file then call the BaseSfGuardUser.setPassword() method, that just do the plain savings
- else call the PluginsfGuardUser.setPassword() method, that expects a clear-text password and encrypts it, checking the algorythm, too
Now, that said, I do not really know if it is possible to check wether data are being imported from a fixture file, but in case, this seems to be a solution.
Moreover, you can't really call BaseSfGuardUser.setPassword() from the SfGuardUser class, since it inherits from PluginsfGuardUser, so you would have to copy the whole bunch of methods to save algorythm, salt and encrypted password to the SfGuardUser class.
UPDATE
Actually, there is a way to know wether the data are imported from the fixtures. As data are imported from fixtures the propel-load-data task invokes the load_data function, and that is a signature.
Yet, it could be that you actually want to import unencrypted passwords (as, for example, when importing the sfGuard plugin users from the plugin). So, you could define an import_encrypted_passwords entry in the app.yml configuration file and set it to 'true' if you want to use encrypted password.
all:
sf_guard_plugin:
import_encrypted_passwords: 'true'
This way, if you don't define this entry, the standard mechanism is used.
Attached you can find the sfGuardUser.php model class, that must be substituted in plugins/sfGuardPlugin/lib/model/
Here is the code of the class
<?php
/*
* This file is part of the symfony package.
* (c) 2004-2006 Fabien Potencier <fabien.potencier@symfony-project.com>
*
* For the full copyright and license information, please view the LICENSE
* file that was distributed with this source code.
*/
/**
*
* @package symfony
* @subpackage plugin
* @author Fabien Potencier <fabien.potencier@symfony-project.com>
* @version SVN: $Id: sfGuardUser.php 7633 2008-02-27 17:54:50Z fabien $
*/
class sfGuardUser extends PluginsfGuardUser
{
public function setPassword($password)
{
// store the backtrace
$bt = debug_backtrace();
// analyze backtrace to see if importing from fixtures
$is_importing = false;
foreach ($bt as $cf)
if ($cf['function'] == 'loadData')
$is_importing = true;
// if importing from fixtures
// AND specifically instructed to import encrypted passwords
// then just save the encrypted password
if ($is_importing &&
sfConfig::get('app_sf_guard_plugin_import_encrypted_passwords', false))
{
if ($password !== null && !is_string($password)) {
$password = (string) $password;
}
if ($this->password !== $password) {
$this->password = $password;
$this->modifiedColumns[] = sfGuardUserPeer::PASSWORD;
}
} else
parent::setPassword($password);
}
}
[Updated on: Wed, 21 May 2008 12:42]
|
|
|
Members
Search
FAQ
Register
Login
Home
) 1 Vote(s)
