Eat my monkeydust

I was just working with a user list using an admin generator, and received a suggestion that username searches should automatically include wildcards in the searches (front and back), so it would not be necessary to add the asterisk. The problem was that the list was based on the sfGuardUser plugin, and we all know that modifying the contents of a plugin can be bad news.

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.

It seems that the sfGuard plugin only checks the “remember me” cookie if the user attempts to access a secure module. This is fine if your site requires a login for any access, and thus is always is_secure: on, however if you have any “public” pages which logged in and non-logged in users can access, users that have selected the “remember me” box will not be logged in automatically.

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.

I spent ages looking for  a fix for this and found many forums and many “fixes” which worked for some and not for others. Something that I installed (or maybe un-installed) managed to mess up some registered dlls, and nothing I tried from all the helpful suggestions fixed it.

Until today (type these in a command prompt):

regsvr32 jscript.dll
regsvr32 vbscript.dll
regsvr32 wmp.dll

And wow, I was amazed when media player actually started! So thanks to HighConcept on The Green Button who offered the suggestion. I use mostly iTunes anyway… but it had become annoying with embedded media and a few other things that I was trying to achieve with it.

First of all, the main reason I’m writing this is so that first time visitors to this interesting crag, just minutes away from where I work (Storo in Oslo), will not go through the same hunting process as we did! First of all, the guide book (Klatrefører for Oslo og omegn - 2003) is pretty out of date, 5 years is a long time in a city that likes to keep building - I don’t think you’ll ever see Oslo without a crane or 6 on the skyline. Secondly, the crag is pretty well hidden - so unless you know the exact paths to take, you could well spend a few hours in the forest of dark green broccoli…

We approached along the road, as described by page 53, looking for a locked car park 150m from our path up the steep hill. It was ok to park along side this car park, so we were told… except it doesn’t exist any more - obliterated in what we now realise was probably the new apartment building built into the side of the hill.

After driving up and down the road, between the two solid way-points on the map that we knew we should be between, we settled on a small car park with what looked suspiciously like climbers’ cars. Next to these cars, was a very small, steep path which wound up the hillside. Perfect. About an hour later, and a few litres of sweat, we headed back to the car.

Luckily for us, it was a beautiful day, 6pm in Oslo at this time of year can be pretty warm, and it didn’t disappoint us today. We drove up to the top car park at Grefsenkollen, and after little help from some grumpy truckers, and avoiding the couple who looked like they were doing something they shouldn’t be, we (just Torkjel and I this time) headed into the forest for another look, this time attacking from above.

More sweat later, after zig-zagging across the hill, we eventually hit the lower road again. Still no climbing in sight! After a short jog along the road, we found what looked like a promising path up into the broccoli, so we went for it, only to end up at a solid platform with several discarded “engangsgrill” disposible barbequeues - we had found the viewpoint. Now according to our trusty guidebook, the crag was a little “up and to the left” of the viewpoint, but that turned out to be a lie… So we fetched the girls, parked up at the top car park again and led them to the viewpoint, where we enjoyed our own barbequeue and soaked up the sun and the view, and I got to play a bit with my camera.

During our feast, we spotted a guy who looked like he knew his way around, and Torkjel approached him to ask the ultimate question “dude, where the hell have you hidden the rocks?” (well, I wasn’t there but I imagine that’s what he said…) and he said “they are just down there, to the right“. So Torkjel took off on a little recce, and sure enough he came back with a big grin on his face, we had found the crag, and it had only taken us about 2 hours!

All in all it was a great evening. We got a good workout in the forest - I love orienteering so running through trees was no chore, we had a barbequeue with a stunning view of Oslo, and we climbed 3 good routes, all before 10pm.

• Beinbrudd - Bolted, Russ led Cecilie second, Torkjel third
• Svaet I - Traditional protection, Russ led Torkjel second, Cec third
• Svaet II - Toproped central line variant

More pictures are available in the gallery at gallery.walkandclimb.co.uk and via Facebook for those of you looky enough to be friends Cecilie has also blogged a bit about this here.

The crag can be easily seen on gulesider.no - refer to the picture below. The yellow x is the viewpoint, the blue line is the crag, and the red circle is the approximate location of the hole in the fence that you have to crawl under to gain access to the crag! It’s easy to spot from the road if you are driving past - it’s the only part of the huge wire fence you could imagine crawling under, and has obvious erosion where many a climber has trodden before you.

I didn’t bother to take GPS coordinates while I was there, but my guesses from Google Earth, based on the Gulesider arial photo are as follows:

Viewpoint:
59°57′23.94″N  10°48′0.04″E
Crag:
59°57′22.03″N  10°47′57.34″E
Hole in the fence:
59°57′24.44″N  10°47′54.06″E

If anyone wants to correct me on those, please feel free! I’ll be sure to verify them myself the next time we are there - but if you do spend 2 hours trying to find the crag, I hope you have as much fun as we did in the process!

Another point to note - which I’ll expand on next time we visit with a bit more time, is that a lot of the routes seem to be bolted now with new Petzl Limbolts. The guide book indicates that all the routes are trad… I’ll take a better look next time, and maybe save someone the trouble of taking along a lot of gear for their first visit!

Russ.