Question

我正在使用带有FOS用户包的Symfony 3.1。

我第一次登录时以隐身模式收到登录表单的“CSRF无效令牌”消息

我注意到在第一个请求中，我得到了一个令牌。然后我刷新页面并获得另一个页面。从那时起，我得到相同的标记（并且正常工作）。例如：

1st request: maJl7bBRR0iuOX4A96cOxrsLdklBIxz3mCP7fSMGqQY
2nd request: q21SVH98tbMLeRIypv2aTn0xBDXJ1khrcL8fIMOU4Y8
3rd request: q21SVH98tbMLeRIypv2aTn0xBDXJ1khrcL8fIMOU4Y8
4th request: q21SVH98tbMLeRIypv2aTn0xBDXJ1khrcL8fIMOU4Y8

我测试了两次导致相同的行为。

由于标题：

，它似乎不是浏览器缓存问题

Cache-Control:no-cache

表单中的csrf输入生成如下：

<input type="hidden" name="_csrf_token" value="{{ csrf_token('authenticate') }}">

第一次失败后，一切正常（第二个csrf令牌正常工作）

我希望在我第一次登录时不会因为CSRF令牌而失败，我怀疑因为上面提到的而失败了。删除CSRF保护不是解决方案。

谢谢！

更新

我发现问题但不是解决方案。该项目将会话数据存储在MySQL中。它第一次访问它时不会将数据插入数据库中，而是第二次将数据插入数据库中。数据存在于$ _SESSION中，但由于它没有第一次存储在MySQL中，因此csrf令牌丢失了。（我发现这记录了应用程序通过此How to show the last queries executed on MySQL?生成的查询）。

将会话存储在文件中可以正常工作。这不是一个解决方案，因为在不同的服务器中会有多个应用程序实例。

Answer 1

问题在于，在几乎所有应用程序中使用的服务中，都有一个

$session = new Session();

由于某种原因导致PDO会话处理程序无法设置。

解决方案是将会话注入服务

 public function __construct(..., Session $session)

并在service.yml中注入，如

 - '@session'

Symfony 3.1 CSRF令牌在登录表单中无效

1 个答案: