Отправка запроса POST в защищенное действие

у меня есть действие, которое принимает данные POST, защищенные sfGuard. Это означает, что если пользователь не вошел в систему, данные POST будут отправлены в форму входа. Обычно это не проблема, пользователь продолжает входить в систему и должен снова отправить данные.

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

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

это недостаток sfGuard, его можно избежать, или я делаю что-то неправильно вообще?

чтобы уточнить, маршрут выглядит так:

add_subgroup:
  url:      /group/:id/add
  class:    sfPropelRoute
  options:
    model:  Group
    type:   object
  param:    { module: subgroups, action: create }
  requirements:
    group_id: d+
    sf_method: [post]

для отправки запроса используется следующая форма:

<form action="<?php echo url_for('add_subgroup', $group) ?>" method="post">
  <input type="hidden" name="group_id" value="<?php echo $group->getId() ?>" />
  <input type="text" name="subgroup_id" />
  <input type="submit" class="button" value="Add" />
</form>
9
php post sfguard symfony-1.4 symfony1

2 ответов

это недостаток sfGuard, потому что действие signin будет проверять запрос POST, и если это так, свяжите форму.

из кода в BasesfGuardActions.класс.на PHP:

if ($request->isMethod('post'))
{
  $this->form->bind($request->getParameter('signin'));

Я лично не большой поклонник переадресации между действиями в symfony, и, как и в этом случае, я думаю, что более целесообразно перенаправлять, чем переадресовать. Это также решает вашу проблему, потому что это приведет к новому запросу GET. Вы можете выполнить это поведение, расширяя sfGuardBasicSecurityFilter.

class mySecurityFilter extends sfGuardBasicSecurityFilter
{

  protected function forwardToLoginAction()
  {
    $context = $this->getContext();
    // If you want to redirect back to the original URI (note: original POST data will be lost)
    $context->getUser()->setReferer($context->getRequest()->getUri());
    $url = sfConfig::get('sf_login_module') . '/' . sfConfig::get('sf_login_action');
    $context->getController()->redirect($url);
    throw new sfStopException();
  }

}

Теперь в приложении / myapp / config / filters.в формате YML

security:
  class: mySecurityFilter
6

Это, вероятно, потому, что вы помещаете код auth данные входа в то же действие (вероятно, проверяя, является ли запрос post).

однако вы можете разделить одно действие на два действия. Один для отображения формы входа в систему, а другой для аутентификации данных входа пользователя. И установите secure_action на действие, которое просто показывает форму входа в систему.

0