Symfony身份验证 - 无法通过生产中的登录页面获取

Question

我在我的本地开发服务器上设置了Symfony身份验证,它在prod和dev环境中都运行良好,今天我注册了一个域进行测试并将我的代码推送到AWS EC2服务器,我可以进入登录页面没有问题但是一旦我尝试登录,我就会直接重定向回登录页面而不会出现任何错误.似乎当它提交到login_check时,它会直接重定向到/ login.我已尝试使用和不使用调试清除和加热生产缓存,这似乎无法解决问题.我的prod.log文件中没有错误.

有关如何排除故障的任何建议？

谢谢.

编辑: 这是在开发日志中显示的:

[2012-03-26 22:52:59] security.INFO: Authentication request failed: Your session has    timed-out, or you have disabled cookies. [] []
[2012-03-26 22:52:59] security.DEBUG: Redirecting to /login [] []

编辑 每次刷新页面时,我都会获得两个新的cookie sub.domain.com和.domain.com - 如果我在/ tmp/dir中查看保存会话的服务器,则会在每个页面上创建6个新会话刷新,chrome dev工具中显示的两个都没有数据.我的本地开发服务器上不存在此问题.关于什么可能导致这一点的任何建议赞赏!

编辑 - 解决方案

我从Chrome中删除了Cookie,它突然开始工作了.不知道问题的根源是什么,但现在似乎一切正常.

Answer 1

启动Symfony ,配置中2.3有一个require_previous_session设置,将其设置为false:secure.yml

    secured_area:
        ...
        form_login:
            ...
            require_previous_session: false

Answer 2

提示:检查config_prod.yml细微的配置差异.

我在本地机器上测试prod环境时遇到了同样的问题; 虽然我可以在dev上进行身份验证,但我无法对产生OP提到的错误的prod进行身份验证:

security.INFO: Authentication request failed: Your session has timed-out, or you have disabled cookies. [] []

该禁用饼干有点让我思考.

接下来,我检查了浏览器中的网络选项卡,并在我的页面请求/响应时达到了顶峰.我发现会话cookie是在服务器的响应中提供的,但是浏览器没有在请求中发送.

然后我有了我的时刻:

我在未加密的连接上使用安全cookie

在我们的生产服务器上,所有未加密的流量都被重定向到TLS连接,因此在prod环境中使用安全cookie是有意义的.在config_prod.yml中:

framework:
    session:
        cookie_secure: true

结果是会话cookie将secure附加到它:

Set-Cookie:PHPSESSID=66117caf467ef2bf8efee373b52449ba; path=/; secure; HttpOnly

符合浏览器/用户代理:

不会发送带有未加密HTTP请求设置的安全标志的cookie.

gotchya是php的原生会话处理不知道或不关心安全标志(由Symfony添加),因此会话cookie仍然可以通过未加密的连接发送,浏览器(或至少Chrome 35)将 - 令人困惑的时尚 - 实际上使用通过不安全/未加密连接收到的安全cookie.我想这并不令人困惑,服务器负责使会话无效,而不是浏览器.

解

我在我的本地机器上设置了https,这样我就可以测试prod环境而无需配置.仅为生产实施仅https连接可以使我的团队更简单,但确实让我感到沮丧.

拿走:本地和生产之间更高的平价通常更好!

Answer 3

嗯，它在您的本地服务器上运行，因此您肯定启用了 cookie。:)

正如我在评论中所说，您应该检查会话是否在php.ini. 其中包括：

• “会话.保存路径”,
• “会话.自动启动”。

另外，请检查Firebug您是否收到了有效的PHPSESSIDcookie（或任何类似的内容，具体取决于您php.ini）。您可能想要检查的另一件事是config.yml像这样的部分文件：

session:
        default_locale: %locale%
        auto_start:     true
        lifetime:       86400

这些都是疯狂的猜测，但我怀疑“session.save_path”在您的文件系统中不可写......