Karl Katzke

sfGuard is a Symfony plugin that implements a user management and login system for an application. It supports both groups and individual users… and it saves you from having to ‘roll your own’ user administration system. I’m going to walk you through the basic installation. The steps I take are all taken from the Wiki page, but I’ll expound a little bit more about styling and creating a custom registration process.

Authentication and security are important for any application greater than a mere toy. It’s much better practice to implement something that’s standardized and depend on the security of lots of eyes and a decent user-base as opposed to depending on the obscurity of your own code to secure your app. I highly recommend using sfGuard.

First, the usual installation steps — in your project root directory, use

$ symfony plugin-install http://plugins.symfony-project.com/sfGuardPlugin
$     symfony propel-build-all
$     symfony propel-load-data (application name)

The last one is actually important, even if you don’t already have fixtures — you need to load the admin user so that you can log into your application and access these new features that you’re automagically adding. More below the jump.

In $app/config/settings.yml, you’re going to want to configure the proper plugin modules. For your frontend, you’re going to want to configure the Auth module and the RememberMe filter.

$frontend_app/config/settings.yml:

all:
  .settings:
    enabled_modules: [default, sfGuardAuth]

$frontend_app/config/filters.yml:

security: ~
  class: sfGuardBasicSecurityFilter

Now, we’re going to implement the same for the backend, but adding in the administration modules. I added the sfGuardAuth to the backend; the main tutorial intends for you to use the frontend module’s authentication process to authenticate to the backend, but this never made sense to me. In the application I’m working on, I actually have three applications that are all administered at different levels; the frontend is for users, the mid level one is for day to day administration, and there’s a backend for setup and administering very base details of the application itself. Since most people aren’t quite as crazy as I am, I’m just doing frontend and backend for the example.

$backend_app/config/settings.yml:

all:
  .settings:
    enabled_modules: [default, sfGuardAuth, sfGuardUser, sfGuardGroup, sfGuardPermission]

$backend_app/config/filters.yml:

security: ~
  class: sfGuardBasicSecurityFilter

Now let’s make the changes necessary to redirect users to the sfGuard pages instead of your login pages.

In $frontend_app/config/settings.yml:

.all:
  .actions:
    login_module:           sfGuardAuth
    login_action:           signin

    secure_module:          sfGuardAuth
    secure_action:          secure

We also need to change the parent class in myUser.class.php. There’s functionality that the User class needs to be able to talk to the database.

$frontend_app/lib/myUser.class.php:

class myUser extends sfGuardSecurityUser
{
}

Sometimes, I’ve seen the myUser.class.php change made for you by installing the plugin. Don’t depend on that. Also, the myUser change seems to be missing the closing ?> … bad plugin developers, no cookie. Ok, nevermind. All of them are. It’s on purpose. Bad blogger, no cookie.

sfGuard registers the following routes: sf_guard_signin, sf_guard_signout, sf_guard_password automatically unless you specifically tell it not to. If you don’t like the URLs it assigns by default, then set

Now, since I’m forgetful, I change the default for my pages to be secure… that’s in $app/config/security.yml, set is_secure: on… and then set things to be insecure in my module level files where desired. I suggest this route. Security is meant to be established by default.

Clear your cache, and you should be good to go. Unlike most Syfmony plugins, sfGuard’s wiki documentation is pretty good and goes into lots of detail on how to set defaults.