Как работает защита Symfony2 CRSF?

Я предполагаю, что ваш измененный токен не публикуется. Вставьте кубик:

namespace Symfony\Component\Form\Extension\Csrf\CsrfProvider;

class DefaultCsrfProvider implements CsrfProviderInterface
{
    public function isCsrfTokenValid($intention, $token)
    {
        die('csrf token ' . $intention . ' ' . $token);
        return $token === $this->generateCsrfToken($intention);
    }

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

Излишне говорить, что вы также должны очистить кеш.

=======================================================

Обновление 1. После множества комментариев мы определили, что die() не вызывается. Прогресс.

К сожалению, нам все еще нужно проверить, как именно автор настроил свою систему.

Следующий шаг — войти без настройки токена csrf через firebug и убедиться, что оператор die достигнут.

Сообщите так или иначе.

Излишне говорить (но я все равно скажу), убедитесь, что вы вышли из системы, прежде чем пытаться войти снова.

========================================================

Обновление 2. Оператор die не достигается даже при обычном входе в систему.

Итак, теперь моя любимая часть. Бекасная охота. По сути, я сделал ряд предположений, читая вопрос. Необходимо определить, какие предположения были неверными, задав ряд основных вопросов.

1. Какую версию Symfony 2 вы используете. Я предполагаю по крайней мере S2.1.

2. Как узнать, что система зарегистрировала вас? Используете ли вы панель инструментов отладки и показывает ли она, что вы прошли аутентификацию? Что происходит, когда вы пытаетесь войти с неверным паролем?

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

4. Вы на самом деле добавили оператор die в vendor/symfony/symfony/src/Symfony/Component/Form/Csrf/CsrfProvider/DefaultCsrfProvider.php? Вы сохранили файл после редактирования?

5. На самом деле вы используете стандартный процесс form_login, верно? У вас нет кода, который, например, проверяет пароль пользователя?

6. Используете ли вы какие-либо другие пакеты, например, FOSUserBundle?

7. Файл security.yml в вашем вопросе действительно является вашим настоящим файлом? Вы не "подчищали" его после копирования?

8. Вы проверили свое приложение на github? Если да то можно ссылку? Просмотр всего приложения, вероятно, будет самым быстрым способом прояснить это.

Этого должно быть достаточно на данный момент. Обновите свой вопрос своими ответами.

=========================================================================

Обновление 3 - Сюжет сгущается

Когда я набирал вышеприведенные вопросы, мы обнаруживаем, что сама базовая система входа не настроена должным образом. Панель инструментов отладки указала, что пользователь не аутентифицирован. Больше прогресса! Как это часто бывает, симптомы маскировали настоящую проблему.

Система безопасности, пожалуй, самый сложный компонент Symfony 2, с которым обычно приходится взаимодействовать разработчикам. При настройке легко запутаться и сложно устранить неполадки. Одна маленькая опечатка может все испортить. Для разработчика также очень важно иметь представление о том, как реализована безопасность. Если, конечно, вы не являетесь действительно крупной компанией, такой как Target или Home Depot.

Я предлагаю создать новый проект Symfony 2 с помощью composer. Затем пройдите через http://symfony.com/doc/current/book/security.html шаг за шагом и настройте систему безопасности. Пусть это будет некое эталонное приложение для понимания безопасности.

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

==================================================================

Обновление 4 - захватывающий вывод

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

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

Если вы действительно действительно хотите использовать свою собственную систему, начните здесь: Ручная аутентификация пользователя

Но вы бы отказались от одной из основных сильных сторон Symfony без особой причины.

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

Попробуйте удалить этот бит в файле security.yml:

login:
    pattern:  ^/demo/secured/login$
    security: false

И вместо этого переместите его в контекст secure_area и используйте элементы управления доступом для предоставления доступа:

...

form_login:
    check_path: _security_check
    login_path: login
...

access_control:
    - { path: ^/demo/secured/login$, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }

В качестве альтернативы вы можете попробовать добавить context: secured_area для брандмауэра входа в систему. По моему опыту, отсутствие брандмауэра входа в том же контексте, что и безопасная область, не позволяет вам полностью получить доступ к контексту безопасности из вашего контроллера входа.