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.

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.

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.

For the benefit of those of you who cannot link the problem to a specific event, I was lucky in that that’s all I had done beforehand. Unintalling the previous codec pack, and then installing this Vista specific one has solved my problem.

Advanced-Vista-Codec-Package-Download (Softpedia.com)

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.

I just read this article http://www.slate.com/id/2190872 and it was almost like I’d written it myself, so if you want a better understanding of me, and many millions of people like me, take a read… It’s pretty spot on

• Monday - cycle to work, then to norskkurs? Hmm, maybe I’ll have to think about that second part, since I don’t really want to be sat in a classroom smelling like I’ve just run a marathon…
• Tuesday - Volleyball
• Wednesday - same as Monday
• Thursday - cycle to work, climb in evening
• Friday - rest
• Weekend - Hoping for some climbing/orienteering or at least get out for a run in the forest

My “diet” has been going ok - finding more and more things to keep me full, but generally just relying on endless amounts of fruit, rice cakes and smoothies to keep me going during the work day! Still don’t feel 100% but cutting out the dairy has certainly helped.

Some people have found success by installing the Nvidia drivers from their website instead of using the ones packaged with Hardy, however this also does the job nicely:

sudo rm /usr/lib/xorg/modules/libwfb.so
sudo ln -s /usr/lib/nvidia/libwfb.so.xserver-xorg-core /usr/lib/xorg/modules/libwfb.so

You are only deleting and recreating a symbolic link, so it’s nothing too drastic that you should be worried about trying. Just log out and back in again after doing it and you should see “normal” shadows which you can go ahead and edit on the “window decoration” section of the Compiz settings.