Symfony sfGuardUser hasCrendential работает после обновления

Я использую symfony 1.4 и sfGuardDoctrinePlugin, я установил и настроил его нормально, но у меня есть следующая проблема:

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

Это можно обойти?

Я не уверен, насколько легко это будет исправить. Когда пользователь входит в систему, я думаю, что его учетные данные тут же добавляются к атрибутам сеанса. Поэтому, когда администратор обновляет свои учетные данные, его сеанс по-прежнему содержит старые учетные данные. Это означает, что любой вызов hasCredential не является «живым».

Спасибо


person Del    schedule 21.09.2010    source источник


Ответы (3)


Это добавит дополнительные запросы к каждому запросу вашего приложения. Вы можете принудительно обновить учетные данные с помощью $user->getSfGuardUser()->refresh(true), что перезагрузит объект и все его отношения (и, следовательно, его разрешения).

person Bouke    schedule 21.09.2010
comment
Вы можете уменьшить влияние, выполняя это, скажем, только при одной из каждых 10 загрузок страниц: if (1 == rand(1,10)) { $user->getSfGuardUser()->refresh(true); } Это значительно уменьшит влияние. Последствием будет небольшая задержка между изменением учетных данных и обновленными разрешениями, но не будет необходимости выходить из системы. - person lonesomeday; 21.09.2010

Спасибо за ваш ответ, я изменил функцию processForm класса действий модуля sfGuardUser.

Если я войду в систему и изменю свои собственные разрешения, сеанс будет обновлен тут же.

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

База данных сеансов имеет следующие столбцы: sess_id, sess_data, sess_time.

sess_data сериализуется, и это то, что мне нужно обновить.

Но я думаю, что symfony довольно часто обновляет идентификаторы сеансов, и было бы трудно всегда изолировать правильный сеанс для другого пользователя.

Я думаю, что было бы также медленно пытаться десериализовать, проверить user_id, а затем повторно сериализовать данные. Думаю, мне понадобится столбец user_id.

person Del1    schedule 22.09.2010

Я знаю, что это старый вопрос, но недавно у меня была такая же проблема, и мне потребовалось гораздо больше времени, чем нужно, чтобы найти ответ (который был опубликован в разделе фрагментов кода Symfony). Вставьте эту функцию в свой класс myUser, и все проблемы исчезнут:

/**
   * Overridden method that actually reads the permission from DB
   * instead of relying on data present when the user logs in.
   *
   * @param  string  permission name
   *
   * @return boolean true if the user has credential
   */
  public function hasCredential($permission_name)
  {
    if (!$this->isAuthenticated()) {
      return false;
    }
    $gu = $this->getGuardUser();
    $groups = $gu->getGroups();
    $permissions = $gu->getPermissions();

    $permission_names = array();
    foreach($permissions as $permission) {
      $permission_names[] = $permission->getName();
    }
    foreach($groups as $group) {
      $group_permissions = $group->getPermissions();
      foreach($group_permissions as $group_permission) {
        $permission_names = array_merge($permission_names, array($group_permission->getName()));
      }
    }
    $permission_names = array_unique($permission_names);
    return (in_array($permission_name, $permission_names)) ? true : false;
    }
person Patrick    schedule 23.02.2012
comment
Почему бы просто не вызвать sfContext::getInstance()->getUser->getGuardUser()->refresh(true) в методе действий preExecute()? Я только что столкнулся с этой проблемой, и мне было интересно, какие стены вы ударили, прежде чем заняться этим самостоятельно. - person yellottyellott; 29.06.2012