auth problems (security filters) in sfGuardUser Symfony

I'm using Symfony 1.2.7, and sfGuardUser Plugin. I'm able to view all the pages, login and logout. However when I try to edit (just going to the form) or update an object (saving the changes) sometimes I have problems of auth, and symfony redirects me to the edit form page again. I put some emphasys on sometimes because it's what it's driving me crazy :)

Users have cookies and the remember_cookie. I'm using the cookie domain ".domain.com" for both cookies because we work with subdomains.

On filters.yml I h开发者_JAVA技巧ave the following:

security: ~

remember:
  class:   sfGuardBasicSecurityFilter

that filter is the one used by many:

class sfGuardBasicSecurityFilter extends sfFilter
{
  public function execute ($filterChain)
  {
    if ($this->isFirstCall() && !$this->getContext()->getUser()->isAuthenticated())
    {
      if ($cookie = $this->getContext()->getRequest()->getCookie(sfConfig::get('app_sf_guard_plugin_remember_cookie_name', 'sfRemember')))
      {
        $q = Doctrine_Query::create()
              ->from('sfGuardRememberKey r')
              ->innerJoin('r.sfGuardUser u')
              ->where('r.remember_key = ?', $cookie);

        if ($q->count())
        {
          $this->getContext()->getUser()->signIn($q->fetchOne()->sfGuardUser);
        }
      }
    }

    $filterChain->execute();
  }
}

On the module/config/security.yml

edit:
  is_secure:   on

update:
  is_secure:   on

Looking at http headers, it returs me a HTTP 302 answer. If I look at the code that provokes that redirection; I've noticed that it seems like just before the edit or update action it doesn't recognize the user:

Jul 08 19:03:15 symfony [info] {sfFilterChain} Executing filter "sfBasicSecurityFilter"
Jul 08 19:03:15 symfony [info] {sfFilterChain} Executing filter "sfRenderingFilter"
Jul 08 19:03:15 symfony [info] {sfFilterChain} Executing filter "sfGuardBasicSecurityFilter"
Jul 08 19:03:15 symfony [info] {sfDoctrineLogger} executeQuery : SELECT COUNT(*) AS num_results FROM (SELECT s.id, s.ip_address FROM sf_guard_remember_key s ...
Jul 08 19:03:16 symfony [info] {sfDoctrineLogger} executeQuery : SELECT s.id AS s__id, s.user_id AS s__user_id, s.remember_key AS s__remember_key, s.ip_address ...
Jul 08 19:03:16 symfony [info] {myUser} User is authenticated
Jul 08 19:03:16 symfony [info] {sfDoctrineLogger} executeQuery : SELECT s.id AS s__id, s.name AS s__name, s.description AS s__description, s.created_at AS ....
Jul 08 19:03:16 symfony [info] {sfDoctrineLogger} executeQuery : SELECT s.id AS s__id, s.name AS s__name, s.description AS s__description, s.created_at AS ....
Jul 08 19:03:16 symfony [info] {myUser} Add credential(s) ""
Jul 08 19:03:16 symfony [info] {sfDoctrineLogger} executeQuery : UPDATE sf_guard_user SET last_login = ?, updated_at = ? WHERE id = ? - (...
Jul 08 19:03:16 symfony [info] {sfFilterChain} Executing filter "subdomainFilter"

Any idea on where can I keep looking or how I can fix it?

Thanks a lot!

Hey, I was suffering from something very similar on symfony 1.4.

Basically what was happening was that I would login on to my app and then suddenly be redirected to the login page again when I tried to interact with the page. This was really strange because on my dev machine things worked fine. On the host server my code would log me in and then if I refreshed the page or tried to do any action I'd be redirected to the login screen. Refreshing a couple of times made the resource I was trying to reach pop up and disappear on and off. It was very weird and there was no pattern, I couldn't figure it out until I read your post. I then called up my hosting company to see if they were doing some sort of load-balancing and whether they were sharing the session information properly across the servers.

Apparently they had messed up the session path and so some of my requests were going to servers that had no clue what the session was like-those redirected me to the login screen-the original servers had the proper session path so when they would servicing my requests, things would act normal again. Cheers,

fixed, it was a problem of having two servers running at the same time. We have changed to use Memcache for cookie storing.