Symfony authentication - can't get past login page in production

Question

I've set up Symfony authentication on my local dev server, it works perfectly in both prod and dev environments, today I registered a domain for testing and pushed my code up to an AWS EC2 server, I can get to the login page no problems but as soon as I try to login I get redirected straight back to the login page without any error. It seems as though when it is submitting to login_check it redirects straight back to /login. I've tried clearing and warming the production cache with and without debug, which doesn't seem to solve the problem. There are no errors in my prod.log file.

Any suggestions on how to troubleshoot?

Thank you.

Edit: This is showing up in the dev 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 [] []

Edit Every time I refresh the page I get two new cookies sub.domain.com and .domain.com -- If i look on the server in the /tmp/ dir where the sessions are saved, 6 new sessions are created on each page refresh, the two that are shown in chrome dev tools both have no data inside them. This problem does not exist on my local dev server. Any suggestions on what could be causing this appreciated!!!

Edit -- Resolution

I deleted the cookies from Chrome and it suddenly started working. Not sure what the root of the problem was but all seems to be working just fine now.

Solution 1

Well, it works on your local server so you definitely have cookies enabled. :)

As I said in the comment you should check if session was setup properly in php.ini. This includes, among others:

• "session.save_path",
• "session.auto_start".

Also, check in Firebug that you have received valid PHPSESSID cookie (or anything similar, depending on you php.ini). Another thing you might want to check is config.yml file for part like this:

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

These are all wild guesses but I suspect that "session.save_path" is not writable in your filesystem...

Solution 2

Starting Symfony 2.3 there is a require_previous_session setting in the secure.yml configuration, set it to false:

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

Solution 3

Tip: Check config_prod.yml for subtle configuration differences.

I encountered the same problem while testing the prod environment on my local machine; while I could authenticate on dev, I couldn't authenticate on prod which gave the error mentioned by the OP:

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

The disabled cookies bit got me thinking.

Next I checked the network tab in my browser and peaked at my request/response for the page. I observed that the session cookie was being provided in the server's response, but wasn't being sent by the browser in the request.

Then I had my aha moment:

I was using secure cookies on an unencrypted connection

On our production server all unencrypted traffic is redirected to a TLS connection, so it made sense to use secure cookies in the prod environment; in config_prod.yml:

framework:
    session:
        cookie_secure: true

The effect is that the session cookie will have secure appended to it:

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

conforming browsers/users-agents:

will not send a cookie with the secure flag set over an unencrypted HTTP request.

The gotchya being that php's native session handling doesn't know or care about the secure flag (it's added by Symfony), so the session cookie can still be sent over an unencrypted connection and the browser (or at least Chrome 35) will — in a baffling fashion — actually use a secure cookie received via an insecure/unencrypted connection. I guess it's not that baffling, it's the servers responsibility to invalidate sessions, not the browsers.

Solution

I setup https on my local machine so I can test the prod environment without futzing with configuration. Enforcing https-only connections only for production kept things simpler for my team, but did trip me up a little.

Take away: higher parity between local and production is usually better!