Installing sfGuardPlugin in symfony 1.1 — A Guide for the Perplexed

by barce on August 18, 2008

Like the verbally creative barfly, who is a dead ringer for a 21+ Juno, that you picked up during last call on a Friday night, symfony 1.1 starts to grow on you. Nevermind your friends, who found Erlang in some higher-scale, hipster, hippy hang out. They tell you it’s time to leave symfony 1.1. You’re perversely drawn to this framework and don’t mind racking up the future therapy bills.

God is dead, and so everything is permitted, unless you can install something like symfony 1.1’s sfGuardPlugin to add logins and login protection to web pages. Like the initiation rites into the Eleusinian mysteries or the Freemasons, not everything is articulated on how to do the install. But below, for the first time, it is.

Note: I use psymfony as an alias which really just means ‘php symfony’.

  • psymfony generate:app backend

Now you can start following the guide written on the symfony website. Below is just from my shell’s history log:

  • psymfony plugin:install sfGuardPlugin
  • psymfony propel:build-model
  • psymfony propel:build-sql
  • psymfony propel:insert-sql — this didn’t work for me so I ended up just doing: mysql -uusername -p < data/sql/plugins.sfGuardPlugin.lib.model.schema.sql
  • follow the instructions in the guide above for fixtures
  • psymfony propel:data-load frontend
  • psymfony propel:data-load backend
  • vim apps/frontend/config/settings.yml
  • vim apps/backend/config/settings.yml
  • psymfony cc

But you’re not done yet. Are you running into a propel connection error? Then you might have to edit some yaml files based on this blog post.

In my case, I ended up having to edit config/databases.yaml by adding the following below:

   propel:
     class:          sfPropelDatabase
     param:
       phptype: mysql
       host: localhost
       database: dev_starster
       username: writes
       password: some_wicked_sick_password
       dsn:          mysql://writes@localhost/dev_starster
       datasource: propel

Are we out of the woods yet?

Unfortunately, symfony 1.1 has a signout bug, where sessions are not entirely cleared. Thanks to this blog post, I was able to hack something together.

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

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

You might have to link the sf_guard_user table to an account table, if you want the account table to do the authorization instead. If so edit apps/modulename/config/app.yml by adding something that looks like this:

  sf_guard_plugin:
    algorithm_callable: md5
    success_signin_url: @homepage
    profile_class: sfGuardUserProfile
    profile_field_name: account_id
    check_password_callable: [Account, checkPassword]

In the lib/model/Account.php you should add code that looks like this:

  public static function checkPassword($username, $password) {
  	$c = new Criteria();
  	$c->add(AccountPeer::EMAIL, $username);
  	$c->add(AccountPeer::PASSWORD, md5($password));
  	$rac = AccountPeer::doSelect($c);
  	//print_r($rac) ; die();
  	if ($rac == TRUE) {
  		return TRUE;
  	} else {
  		return FALSE;
  	}
  }

Here is a list of links that made getting the plugin working possible:

{ 7 comments… read them below or add one }

Teikweidi August 25, 2008 at 9:22 pm

Hi Jim,

I could have used your post earlier, but I setup my sfGuardPlugin a little bit before your post. I am using Symfony 1.1, Propel 1.3, and database session management. I have a question that is the natural next step to sfGuard setup.

Do you know of any good tutorial for how to test a module/action behind sfGuardAuth? I looked at the plugin and I don’t see any tests included with it. I looked on Google, and didn’t see anything posted (a functional test tutorial, complete with session integration would be great). Even functional testing source code for other small projects would do the trick. I even tried to look for the subversion repository associated with sfGuard to see if tests where in the repository. I tried posting to the Symfony Forum, got 65 views, but no suggestions. I was hoping that maybe you are in the same boat, and could shed some light on it.

Thanks.

Leonardo Diaz August 26, 2008 at 7:37 am

I think you does not need to hack the plugin, its better left the plugin clean, so you can update later when the bug is resolved. Fortunatelly symfony lets you use your own module and action for that purpose. So if you need to change the method then you can create a module with the name of the plugin and in the actions file, you code your own method to logout, symfony handles the rest. I must say that I have not done this with sfGuardPlugin but with other ones, so I pressume it works with this one.

barce August 26, 2008 at 3:50 pm

@Leonardo Diaz Yes, you are correct. I put all the code I need in the project/apps/sfGuardAuth folder.

@Teikweidi I took a look at the source code and no, you can’t do functional testing with sfGuardAuth on. If you look at the source for utils/sfBrowser.php you’ll see a line that says, “FIXME.” Below that line, you’ll see that there is no code for handling sfGuardAuth for functional tests.

For now, I recommend using Selenium IDE.

http://selenium-ide.openqa.org/

Kévin Dunglas October 14, 2008 at 8:51 am

Hi,
thanks for this how-to.

To avoid PHP’s strict standards errors use this snippet:

public function executeSignout($request) {
session_destroy();
session_write_close();
session_regenerate_id();

parent::executeSignout($request);
}

It just respect the method signature 🙂

Have

Kévin Dunglas October 14, 2008 at 8:51 am

… a nice day 🙂

Thomas Boerger November 26, 2008 at 7:11 am
Thomas Boerger November 26, 2008 at 7:23 am

If you really want to clear everything on the session try soemthing like this:

public function executeSignout($request) {
$this->getUser()->getParameterHolder()->clear();
parent::executeSignout($request);
}

Leave a Comment

{ 1 trackback }

Previous post:

Next post: