This only came to light recently, when I was scratching my head over why a parameter I had set was still available in the $sf_params array even after logging out, and logging back in again as a different user. This threw up an interesting security issue, because I started to wonder if I’d set any admin specific parameters elsewhere which could be reused by another user on the same machine.

The fix is fairly straightforward, but can only be run when not in test mode, because sfBrowser does not like the session to be destroyed! Maybe this is why it has never been written into the core functionality?

In apps/yourapp/modules/sfGuardAuth/actions/actions.class.php

 public function executeSignout()
   {
     if (sfConfig::get('sf_environment') != 'test')
     {
        session_destroy();
        session_write_close();
        session_regenerate_id();
     }
     parent::executeSignout();
   }

Adding the parent::executeSignout() line means that you can let the sfGuard plugin do the remainder of the work for you, so rather than overriding the function, you are just adding a bit to the start of it.

The way to do this without modifying the plugin, is to override the action that is being called, and then call the parent method. In this case, the action that was processing the form submission was sfGuardUserActions->executeList(). So in apps/yourapp/modules/sfGuardUser/actions/actions.class.php add the following:

  public function executeList()
  {
    //Add fields to auto-wildcard to this list
    $wildcardFields = array("username");
 
    if ($filters = $this->getRequestParameter("filters"))
    {
      $originalFilters = $filters;
 
      foreach ($wildcardFields as $fieldName)
      {
        // Only add the wildcards if the user is not already using them
        if (strpos($filters[$fieldName], "*") === false)
        {
          $filters[$fieldName]  = "*".$filters[$fieldName]."*";
        }
      }
      $this->getRequest()->getParameterHolder()->set("filters", $filters);
    }
    parent::executeList();
 
    // Set the filters back to their original values before the template is rendered
    $this->filters = $original;
  }

Now the request parameters for the selected fields are automatically prepended and appended with an asterisk before calling the parent function of the same name to continue with the request. Once the parent has finished, we then set the filters back to their original value, otherwise the asterisks we added would now appear in the fields when the page is presented.

An enhancement to this would be to specify the auto-wildcards field in the .yml file, rather than specifying it here in the action.

Solution:

Of course this could be fixed in the plugin, but if you do not want to (and shouldn’t) modify the plugin code directly, you can add another filter which will check the cookie. Assuming you have already installed the sfGuardPlugin, and have a “remember me” checkbox implemented, this is all you will need to do to get the automatic logins on non-secure pages:

in apps/yourapp/config/filters.yml add the remember me filter

rendering: ~
web_debug: ~
security:
  class: sfGuardBasicSecurityFilter
 
# generally, you will want to insert your own filters here
 
remember:
  class: rememberMeFilter
 
cache:     ~
common:    ~
flash:     ~
execution: ~

Now create rememberMeFilter.class.php in apps/yourapp/lib
This example uses Propel

class rememberMeFilter extends sfFilter
{
  public function execute ($filterChain)
  {
    // execute this filter only once, and if the user is not already logged in, and has a cookie set
    if ($this->isFirstCall() && !$this->getContext()->getUser()->isAuthenticated()
        && $this->getContext()->getRequest()->getCookie(sfConfig::get('app_sf_guard_plugin_remember_cookie_name', 'sfRemember')))
    {
      // See if a user exists with this cookie in the remember database
      $c = new Criteria();
      $c->add(sfGuardRememberKeyPeer::REMEMBER_KEY, $this->getContext()->getRequest()->getCookie(sfConfig::get('app_sf_guard_plugin_remember_cookie_name', 'sfRemember')));
      $c->add(sfGuardRememberKeyPeer::IP_ADDRESS, $this->getContext()->getRequest()->getHttpHeader ('addr','remote'));
 
      if ($resultArray = sfGuardRememberKeyPeer::doSelectJoinsfGuardUser($c))
      {
        $resultRow = current($resultArray);
        $this->getContext()->getUser()->signIn($resultRow->getSfGuardUser());
      }
    }
    // execute next filter
    $filterChain->execute();
  }
}

That should do it, now your users will be logged in on any page if they have the cookie set. The sfGuardPlugin will still take care of setting the cookie and clearing it on logout.

Remember when using these cookies, it’s good practice to ask the user to re-enter their password when doing anything sensitive, like submitting an order or changing any personal details like their password.

A follow up by Shiny explains that you can also get this working by securing modules with empty permission sets like this:

all:
  is_secure: on
 
index:
  credentials: []

Be careful with setting that globally though if you’re trying to set a “secure it first, grant permissions later” style system, because with the above - everything is accessible until secured.

default_culture:   en
// No problem, en is treated as a string 
// and /en/ is automatically added to links
 
default_culture: no
// Oops, no is translated by Symfony 
// the same way as false, 0 or off, giving it a boolean value!
 
default_culture: 'no'
// That's better, now you will have the intended results.

The same applies to any yml files that you may have “keywords” in, so try to always use quotes round everything that is not boolean, integer, etc.

http://propel.jondh.me.uk/

It’s developed by a Symfony user, and allows you to type in sql statements using nested braces for prioritising. The form will then return a nicely formatted block of Propel code.

It’s not perfect, and it doesn’t cover everything just yet, but it’s great for getting some ideas about the structure and how to use various criteria - it’s also spot on if you are trying to learn Propel and already know how to structure SQL statements.

Discuss this tool and/or contribute on the Symfony Forum

Using a combination of tools like this, and taking a look at the generated files in lib/model/om should give you a good push, and a bit of a shortcut to more complex queries than you may be used to - rather than having to trawl the Propel documentation.

Symfony does not delete these unused files when you run a build, so they will stack up and cause Propel errors, for example when calling propel-dump-data.

Of course you can safely delete the lib/om and lib/map folders and run the build again, but you should manually delete the relevant files in /lib as there could be some user generated content in there also. These files are unlikely to cause any errors but might as well be deleted as part of your clean up since they are effectively useless if you have removed their referenced tables from the schema.

As your site grows, and you add more and more config to the app.yml file, be very careful not to re-declare the same named element. Symfony will not warn you, and there will be no errors - but the second (lower) instance will simple overwrite the first!

For example, if you have forgotten that you already have an element called profile hiding near the top of the file, and you add another one called profile at the bottom, with all your profile page settings - the lower one will destroy the one higher in the file.

This can be hard to spot if you have been meticulously coding and added a default value to all your sfConfig::get() calls because chances are when you are developing the site, all your defaults will be the same as the ones you have specified in app.yml.

The problem will become apparent when an end user tries to change the configuration and the change is ignored, because Symfony is simply using the default value rather than the one the user thinks they are setting.

Careful out there kids!

UTF-8 characters can be multi-byte, and strlen() returns the length of the string in bytes, which means the string ååå would actually have a “length” of 6.

One solution is to use the multibyte function “mb_strlen” instead, you will need to have PHP compiled with this - but it seems to be a default in later versions.

E.g.

$value = "ÅØÆbob";
echo strlen($value);
// 9
 
echo mb_strlen($value, 'UTF-8');
// 6

There is a bug in Symfony’s email validator which means that unless you use both modes (strict and non-strict) invalid email addresses are possible.

Time of writing we are at version 1.0.13 - this could well be (and probably will be) fixed in 1.1 but please let me know if you spot that this has been fixed beforehand.

Strict mode validation

This mode is intended to catch email addresses such as root@localhost, but unfortunately it does not check for valid email strings, so %,%@hotmail.com would be accepted, as well as many other illegal character combinations.

Non-strict mode

This mode checks that the email address contains legal characters, but does not check for internal addresses. This is fine for most cases, but it is worth restricting users from using your site to spam your local mail server.

Solution 1

Sapheriel suggests on his blog that one solution is to override the functionality of the class, and then restore it once an update has been released.

“The best way to achieve this with the least amount of intrusion is to copy sfEmailValidator.class.php into your project’s library folder, modify it, and delete it once a fix has been published”

This may suit many users

Solution 2

If you do not want to worry about something you may have to do in the future, you can also run the validator twice, for example in your validator.yml file:

DoubleCheckEmailValidator:
  class: sfEmailValidator
  param:
    class: sfGuardUser
    column: email
    strict: true
    email_error: This email address is invalid
 
fields:
  email:
    required:
      msg: Please enter an email address
    sfEmailValidator:
      email_error: This email address is invalid
      strict: false
    sfPropelUniqueValidator:
      class: sfGuardUser
      column: email
      unique_error: This email is already in use
    doubleCheckEmailValidator:

You could also write a custom validator which calls the email validator twice, however we have opted for this solution for now.

Thanks to June for the content.

Other than some Java training at university, and the odd borrowed third-party classes (notably phpclasses.org) my PHP background up to this point was purely based on procedural style programming. I’d worked on some big projects, some I’m proud of and some I really want to go back to and rewrite from scratch, a sentence I’m sure you will hear from many “code monkeys”.

Symfony for me, was my first breach into the much hyped object oriented style PHP5 - and a whole new way of thinking. In the following articles, I hope to share with you the experiences I have had, with PHP5, Symfony and any other related technologies that I stumble across.

One of the things I have realised in the last few weeks, is that when searching for answers to problems that are not well documented, the most common results are in the form of developer blogs. Some of these have been invaluable to me and I’d like to credit them here, I’d also like this to become one of those blogs - since some of the answers I have sought have not been so easily forthcoming.