Symfony: вопрос о куске кода sfDoctrineGuardPlugin

Question

этот код приведен ниже в sfDoctrineGuardPlugin.

$a = sfConfig::get('app_sf_guard_plugin_success_signin_url');

var_dump($a);

$signinUrl = sfConfig::get('app_sf_guard_plugin_success_signin_url', $user->getReferer($request->getReferer()));

var_dump($signinUrl);

var_dump($user->getReferer($request->getReferer()));

Он печатает это:

ноль

строка 'http://rs3.localhost/frontend_dev.php/' (длина= 38)

строка 'http://rs3.localhost/frontend_dev.php/miembros' (длина = 46)

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

С уважением

Хави

Answer 1

sfDoctrineGuardPlugin устанавливает атрибут referer в пользователе, чтобы он мог перенаправить обратно на страницу, первоначально запрошенную. Когда вы звоните getReferer, он удаляет атрибут. (Это вызывает у меня ошибки, что и привело меня сюда.)

Answer 2

Ицньютон указал мне на решение.Класс sfGuardSecurityUser использует метод setReferer, который сохраняет атрибут referer, но только если он еще не установлен.

Если каким-то образом вам удастся дважды получить доступ к методу executeSignin в действиях sfGuard, будет сохранен только первый атрибут referer.это означает, что во второй раз referer в запросе и referer в пользовательском атрибуте могут отличаться.

Метод getReferer удаляет этот атрибут и возвращается к запросному рефереру, когда атрибут не установлен.это объясняет, почему при вызове $ user-> getReferer ($ request-> getReferer ()) дважды иногда возвращаются разные значения.

Я нашел решение переписать метод setReferer sfGuardSecurityUser в классе myUser:

public function setReferer($referer) {
    $this->setAttribute('referer', $referer);
}

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

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

Answer 3

Weird.Жуткий.

Интересно, возможно, два вызова getReferer() находятся в разных контекстах?Может быть, первый (как второй аргумент sfConfig::get()) неявно использует __toString(), тогда как при использовании var_dump(), возможно, он печатает необработанное значение объекта referer?getReferer() возвращает строку, так что это, вероятно, не так.

Что вы пытаетесь сделать, кстати?Разве это не соблюдение вашей настройки app_sf_guard_plugin_success_signin_url из app.yml?