Symfony2 - Access is denied (user is not fully authenticated)

Question

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 logged in as: anon instead of the user I logged in as. I'm also redirected back to the login page instead of the target path.

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.

There are no errors in my php errors log, or listed in the Symfony profiler under Exception or Logs.

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!

This is my security.yml file:

# 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 }

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 mod_php.

Output from Symfony Profiler > Debug:

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 

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.

Thanks in advance for any help provided!

Additional info: I have a VPS running a copy of the site (for client previewing). I dev on my local VM and git push my changes, I then SSH into my VPS and do a git pull to keep my two version in sync.

What's strange is the VPS version does not 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.

Update: Problem started happening after making a large number of edits to the code base and performing a apt-get update and apt-get upgrade 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.

This has me thinking the cause may not be code related and instead could be server related, something in the new version of PHP (5.4.28) that was installed via apt-get upgrade perhaps OR a new php.ini directive maybe?

I've run the Symfony configuration checker tool and everything seems fine!

Weird.

Solution 1

I was struggling with the same problem. I checked almost everything and after that suspecion fell on session handler...

I have

session: ~

changed to:

session:
    handler_id:  ~

More about session handling: http://symfony.com/doc/2.2/components/http_foundation/session_configuration.html#native-php-save-handlers

Solution 2

I had the same issue as you.

While @plewandowski's answer solved my issue, the root cause was that the session.save_path as set in PHP's config was a directory with incorrect permissions.

As a sanity check, run php -i | grep session. and then see if the permissions for the save_path are correct..

In my case, session.save_path => /var/lib/php/sessions => /var/lib/php/sessions

Checking the permissions

vagrant@vps:/var/www/site$ ls -lah /var/lib/php
total 16K
drwxr-xr-x  4 root root 4.0K Aug  5 18:01 .
drwxr-xr-x 56 root root 4.0K Aug  5 20:29 ..
drwxr-xr-x  6 root root 4.0K Aug  5 18:23 modules
drwx-wx-wt  2 root root 4.0K Jul 26 11:05 sessions

In this case, the user under which PHP runs (www) it could not access the directory and caused the issue.

Fixed with sudo chmod 1777 /var/lib/php/sessions/

Solution 3

This problem happens when the PHPSESSID cookie is changing with each request. If that is your case then you should check the PHPSESSID response cookies between these request, I bet you that they are changed. Why is that happening, that is the real question!

Let's assume for a moment that the above assertion is true.

By seeing this cookie changing all the time Symfony/PHP assumes that the session manager have created in fact a new user session, obviously that would require the user to re-authenticate (unless RememberMe=true which wouldn't cause a login page redirection).

For instance, while working in dev environment I had no problem with this session issue. However, as soon I switched to prod environment - and by this I mean (1) I flushed the --env=prod cache then (2) I loaded the production /app.php instead /app_dev.php page - it just started to redirect me to the login page after a successful authentication & request.

Obviously at first I thought that there is a configuration problem, perhaps I'm using a different set of params on these environments. But that wasn't the case. So there must be something else, but what?

I've checked the var/session/prod directory and I saw many sess_xxx files. The same in var/session/dev directory. Obviously that is not OK. So I removed the var/session/{prod,dev} entirely then I reloaded the /app.php page. This created 2-3 sess_xxx files in both environment, in prod but also in dev. That is not good. It is a sign that somehow something sends a request to the app_dev.php which will load the dev enviroment which might log out you automatically (based on your app's security/firewall configuration). I opened the app_dev.php and I added an exit(0) then suddenly everything started to work well. So that was what was happening, somehow these environments were mixed and a call to prod would eventually trigger a call to the dev which would log you out immediately.

For a quick fix some people just change the framework::session::save_path to /tmp, which is going to be shared by both environments and thus you are not going to be logged out although your app will somehow still send a request to both the app.php and app_dev.php but since they used the same session folder they think the session is the same (unchanged). So in general this is a quick fix as long the session path is the same for all environments. However this is not the solution to the problem!

One other fix is to not use the app_dev.php in the same time with app.php (or vice-versa) and by that I mean only one file/env at a time. That's also a quick fix and not the solution.

What I did, but I still don't understand what happened, was to remove entirely the web {assetic,css,js,fonts} (or bin/console assetic:dump --env=prod --no-debug) stuff and recreate them again with --env=prod --no-debug. That did the trick but I still don't understand how that could fix it.

I hope the steps above would help you to trace the cause of your problem better than I did :-)

Solution 4

In Symfony 4, I had this error.

In my entity I didn't have the username and password, just I have to add them.

/** @see \Serializable::serialize() */
public function serialize()
{
    return serialize(array(
        $this->userId,
        $this->userUsername,
        $this->userPassword
        // see section on salt below
        // $this->salt,
    ));
}

/** @see \Serializable::unserialize() */
public function unserialize($serialized)
{
    list (
        $this->userId,
        $this->userUsername,
        $this->userPassword
        // see section on salt below
        // $this->salt
    ) = unserialize($serialized, array('allowed_classes' => false));
}

View more solutions