title: Symfony2 - Access is denied (user is not fully authenticated)
body: <p>I'm developing a website using Symfony2, and until today - had no problem logging in. But now when logging in I'm not correctly authenticated - Symfony profiler lists me as <code>logged in as: anon</code> instead of the user I logged in as. I'm also redirected back to the login page instead of the target path.</p>
  
  <p>The login process consists of a traditional login form (i.e. username + password) with a submit button. All user credentials are stored in MySQL and I've setup a User entity as a provider.</p>
  
  <p>There are no errors in my php errors log, or listed in the Symfony profiler under Exception or Logs.</p>
  
  <p>One observation I've made is nothing is listed under the Session Attributes heading (within Symfony profiler > Request) - normally there would be some security context information listed after successfully logging in, but now it's always empty. I tried setting a basic session variable on the homepage which was partially successful as it gets set and is shown under Session Attributes, but get's cleared whenever attempting to login!</p>
  
  <p>This is my security.yml file:</p>
  
  <pre><code># app/config/security.yml
  
  security:
    encoders:
      Woodcut\UserBundle\Entity\User: sha512
  
    role_hierarchy:
      ROLE_ADMIN:       ROLE_USER
      ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
  
    providers:
      main:
          entity: { class: Woodcut\UserBundle\Entity\User, property: username }
  
    firewalls:
      secured_area:
          pattern:   ^/
          anonymous: ~
          form_login:
              login_path: login
              check_path: login_check
              username_parameter: _username
              success_handler: custom_authentication_handler
              failure_handler: custom_authentication_handler
              #always_use_default_target_path: true
              #default_target_path: /login_router
          logout:
              path: /logout
              target: /
      dev:
          pattern:  ^/(_(profiler|wdt)|css|images|js)/
          security: false
  
  
    access_control:
      - { path: ^/admin, roles: ROLE_ADMIN }
      - { path: ^/ratings/update, roles: ROLE_USER }
      - { path: ^/ratings/new, roles: ROLE_USER }
      - { path: ^/favourite, roles: ROLE_USER }
  </code></pre>
  
  <p>I'm using a typical LAMP stack to run my site with Symfony 2.3.13 and PHP 5.4.28 on a Ubuntu 12.04 Virtual machine. PHP is running as <strong>mod_php</strong>.</p>
  
  <p><strong>Output from Symfony Profiler > Debug:</strong></p>
  
  <pre><code>INFO - Populated SecurityContext with an anonymous Token
  DEBUG - Notified event "kernel.exception" to listener "Symfony\Component\Security\Http\Firewall  \ExceptionListener::onKernelException".
  DEBUG - Access is denied (user is not fully authenticated) by "/vagrant_www/vprojects/woodcut/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/AccessListener.php" at line 70; redirecting to authentication entry point
  DEBUG - Calling Authentication entry point 
  </code></pre>
  
  <p>If someone can please help me determine why users are authenticated as anonymous instead of as themselves that would be great. Been pulling my hear out the last two days trying to find the cause.</p>
  
  <p>Thanks in advance for any help provided!</p>
  
  <p><strong>Additional info</strong>: I have a VPS running a copy of the site (for client previewing). I dev on my local VM and <code>git push</code> my changes, I then SSH into my VPS and do a <code>git pull</code> to keep my two version in sync. </p>
  
  <p>What's strange is the VPS version <strong>does not</strong> exhibit this issue (i.e. login works fine) yet both versions use an identical codebase except for some minor differences in their respective parameters.yml and parameters_dev.yml files.</p>
  
  <p><strong>Update</strong>: Problem started happening after making a large number of edits to the code base and performing a <code>apt-get update</code> and <code>apt-get upgrade</code> on my VM. So in an effort to isolate the possible cause I rolled back to an earlier commit - to see if the problem was code related. But despite rolling back to before my major coding changes, the problem is still there.</p>
  
  <p>This has me thinking the cause <strong>may not</strong> be code related and instead could be server related, something in the new version of PHP (5.4.28) that was installed via <code>apt-get upgrade</code> perhaps OR a new <strong>php.ini</strong> directive maybe?</p>
  
  <p>I've run the Symfony configuration checker tool and everything seems fine!</p>
  
  <p>Weird.</p>