Symfony authentication - login page cannot pass

Question

I installed Symfony authentication on my local dev server, it works fine both in prod and dev environments, today I registered a domain for testing and pushed my code to the AWS EC2 server, I can go to the login page there are no problems, but how as soon as I try to log in, I get a redirect directly to the login page without any errors. It seems that when it goes to login_check, it redirects back to / login. I tried cleaning and warming up the production cache with and without debugging, which does not seem to solve the problem. There are no errors in my prod.log file.

Any suggestions for troubleshooting?

Thanks.

Edit: This is displayed 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 Each time I refresh the page, I get two new cookies: sub.domain.com and .domain.com. If I look at the server in / tmp / dir where the sessions are stored, 6 new sessions are updated on each page, two that are shown in the chrome dev tools do not contain data inside them. This problem does not exist on my local dev server. Any suggestions on what could be causing this were appreciated !!!

Change - Resolution

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

Answer 1

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

As I said in the comment, you should check if the session settings in php.ini correct. This includes, but is not limited to:

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

Also, check Firebug that you received a valid PHPSESSID cookie (or something similar, depending on you php.ini ). Another thing you can check is the config.yml file for this part:

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

These are all wild guesses, but I suspect that "session.save_path" is not being written to the file system ...

Answer 2

Running Symfony 2.3 there is a require_previous_session parameter in secure.yml configuration , set it to false:

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

Answer 3

Tip. Check config_prod.yml for subtle configuration differences.

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

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

Bit turned off cookies cookies made me think.

Then I checked the network tab in my browser and reached the peak of my request / response for the page. I noticed that a session cookie is provided in the server response, but was not sent by the browser in the request.

Then I had my aha moment:

I used secure cookies in an unencrypted connection

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

 framework: session: cookie_secure: true 

The effect is that secure will be added to the session cookie:

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

Relevant browser / agent users:

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

The fact that php session processing does not know or care about a safe flag (it was added by Symfony), so a session cookie can be sent over an unencrypted connection and the browser (or at least Chrome 35) will - in an incomprehensible form - actually use secure cookie received through an insecure / unencrypted connection. I assume that it is not so difficult, it is the responsibility of the servers to cancel the sessions, and not from browsers.

Decision

I install https on my local computer so that I can test the prod environment without the need for configuration with configuration. Executing https-only production-only connections simplified my team, but worked a little.

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