Symfony. sfDoctrineGuardPlugin и data-load

sfDoctrineGuardPlugin позволяет без лишних телодвижений настроить авторизацию пользователей и групп для проекта на Symfony. Есть у него один неприятный «изъян». При использовании doctrine:data-dump и doctrine:data-load напрочь слетают пароли пользователей, по причине того, что при заливке данных из fixtures пароли по новой шифруются. Что бы избежать это неприятности нужно слегка подпатчить один из методов класса PluginsfGuardUser, а именно setPassword

1. Открываем файл plugins/sfDoctrineGuardPlugin/lib/model/doctrine/PluginsfGuardUser.class.php
2. Находим метод setPassword()
3. Изменяем код следующим образом:

public function setPassword($password)
{
  if (!$password && 0 == strlen($password))
  {
    return;
  }

  $fromdump = false;
  if($this->isNew() && $this->getSalt()){
    $fromdump=true;
  }

  if (!$salt = $this->getSalt())
  {
    $salt = md5(rand(100000, 999999).$this->getUsername());
    $this->setSalt($salt);
  }
  $modified = $this->getModified();
  if ((!$algorithm = $this->getAlgorithm()) || (isset($modified['algorithm']) && $modified['algorithm'] == $this->getTable()->getDefaultValueOf('algorithm')))
  {
    $algorithm = sfConfig::get('app_sf_guard_plugin_algorithm_callable', 'sha1');
  }
  $algorithmAsStr = is_array($algorithm) ? $algorithm[0].'::'.$algorithm[1] : $algorithm;
  if (!is_callable($algorithm))
  {
    throw new sfException(sprintf('The algorithm callable "%s" is not callable.', $algorithmAsStr));
  }
  $this->setAlgorithm($algorithmAsStr);

  if($fromdump)
  {
    parent::_set('password',$password);
  } else {
    parent::_set('password', call_user_func_array($algorithm, array($salt.$password)));
  }
}

После этого можно спокойно работать с fixtures, не поправляя с помощью guard:change-password пароли после каждой заливки дампа.

Symfony. sfDoctrineGuardPlugin и data-load

Symfony. sfDoctrineGuardPlugin и data-load: 11 комментариев

    1. gwinn:

      Например так:

      [sourcecode language=»php» wraplines=»true» toolbar=»true»]
      sfGuardUser:
      sfGuardUser_1:
      first_name: null
      last_name: null
      email_address: test@localhost
      username: admin
      algorithm: sha1
      salt: 694563a677ba64ce7903e1148a98f618
      password: 801311a738f907c7362a879c0e0b415b4fdcde5f
      is_active: true
      is_super_admin: true
      last_login: ‘2011-04-13 16:48:39’
      created_at: ‘2011-04-11 14:47:16’
      updated_at: ‘2011-04-13 16:48:39’
      sfGuardUser_2:
      first_name: null
      last_name: null
      email_address: test@localhost
      username: manager
      algorithm: sha1
      salt: 6a28b620aa0ae67481ee323e86c06413
      password: 1da977187272f97a98839ef7943bcb28a27be507
      is_active: true
      is_super_admin: false
      last_login: null
      created_at: ‘2011-04-11 14:48:08’
      updated_at: ‘2011-04-11 14:48:08’
      [/sourcecode]

    1. gwinn:

      Де-факто, перед разворачиванием на продакшене, в фикстурах остаются только самые необходимые стартовые данные, в том числе запись об административной учетной записи, это позволяет сократить количество телодвижений во время деплоя.

  1. Но развёртывание на продакшне просходит *один* раз, не так ли?
    Да и есть же таск guard:create (или как там его), который можно вызвать и из шеллскрипта. достаточно безопасно, ящетаю.

    1. gwinn:

      Все так, но, повторюсь еще раз, таким образом сокращается количество телодвижений, во вторых, есть проекты где есть авторизация, но отключен механизм регистрации (да, есть и такие) и создание новых пользователей осуществляется из-под учетки администратора, то есть для деплоя так или иначе нужны начальные данные (в данном случае именно учетка админа). После заливки исходников такого проекта на сервер выполняется только один task — php symfony doctrine:data-load и все.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *