TW Blog :: Entries for PEAR

Viva PEAR::Cache_Lite

Also relates to PHP

With the latest release of the PEAR::Cache the Cache_DB extension has been removed. I first came across Cache_DB in the PHP Cookbook last year and ran several tests to integrate it as a principle caching mechanism in the Content Management System. However, the class offered no noticeable benefit in performance, and when several database calls were being executed for a single page, it did not make sense to use a cache per query. So as an alternative I decided to test drive the PEAR::Cache_Lite package instead. As its nomenclature suggests, this is an excellent lightweight package and offers the perfect solution for filling the caching void in content retrieval. One of the package extensions is <a href="http://pear.php.net/manual/en/package.default.cache-lite.cache-lite-function.cache-lite-function.php" title="Current End User Documentation on Cache_Lite_Function">Cache_Lite_Function</a>, a caching class for functions. This allows for several database calls and the template system to be wrapped in a single method for caching:

class SS_Content {

  // [..snip..]
  
  function fetch($action, $caching = NULL)
  {
    $this->action = $action;
    
    if ($caching === NULL) {
      if (isset($this->_caching)) {
        $caching = $this->_caching;  
      }
    }
    
    if ($caching === SS_CACHING_ON) {
      return $this->retrieveCache();
    }
    else {
      return $this->retrieve();  
    }   
  }
  
  function retrieveCache() {    
    require_once "Cache/Lite/Function.php";

    $options = array(
      'cacheDir'     => CACHE_DIR,
      'lifeTime'     => CACHE_EXP
    );
    $objCache = new Cache_Lite_Function($options);
    return $objCache->call(
      $GLOBALS['_SS_Content_Obj'] . '->retrieve');           
  }
  
  function retrieve()  { 
  
    // this is where the content is built
    // eg database retrieval and content 
    // creation with a template system
  
  }
  
  // [..snip..]
}

This is only a raw example, since within its actual context, SS_Content is actually an abstract class serving specific modular extensions. But it shows how simple Cache_Lite is to use - create the object and invocate the <a href="http://pear.php.net/manual/en/package.default.cache-lite.cache-lite-function.call.php" title="End user documentation on the call method of Cache_Lite_Function">Cache_Lite_Function::call()</a> method. There is one area of caution when using Cache_Lite in an OOP environment like this. The method will look for an object in the global name space equating to the name preceding the accessor operator in the parameter string of the method. How this is achieved is dependant on the application and naming conventions. One solution is to register the variable name of the object in a global variable during instantiation of the class (as demonstrated above).

Melon Fire provides a terse but detailed introduction to Cache_Lite, Cache_Lite_Function and its counterpart Cache_Lite_Output.

Posted on Jun 20, 2004 at 03:40:35. [Comments for Viva PEAR::Cache_Lite- 0]

PEAR HTTP_Session Package

Also relates to PHP

A few months ago I discussed a method I have adopted for PHP session management. It is a simple process that uses a forced server redirect the first time a user arrives at a page to confirm cookies are enabled for session storage. This allows a message to be displayed to the user if cookies are disabled rather the application failing at the next step (eg after login/registration submission).

I have recently been updating my object-oriented PHP CMS with PEAR packages, to reduce the coding and maintenance I have to perform. The HTTP_Session module is no exception. This is a lightweight interface for all the inbuilt session management functions and as a class it can be readily extended with added functionality. The PHP CMS only stores a session variable for login details to persist the administrator across multiple HTTP requests, so I only really have need for the get and set methods.

HTTP_Session::start();

$user =& new CMS_User;

if (HTTP_Session::get("user")) {
  $user->loggedIn = TRUE;
} 
elseif ($user->requestLogIn()) {
  HTTP_Session::set("user", $user->getDetails());
}

At the same time, I was keen to extend the class with the cookie test described above.

class CMS_Session extends HTTP_Session
{
  [..]
  
  function test()
  {
    if (HTTP_Session::isNew()) {
      if (HTTP_Session::detectID() == NULL) {
        if (!isset($_GET[HTTP_Session::name()])) {         
          $sess_id = substr(SID,(strrpos(SID,"=")+1));
          $redirect_url = CMS . CMS_REDIRECT_QUERY . $sess_id;
          header("Location: " . $redirect_url);
          exit; 
        }
        else {
          $old_id = $_GET[HTTP_Session::name()];
          HTTP_Session::destroy();
          HTTP_Session::start("CMS", $old_id);
          HTTP_Session::destroy();
          throw_error(
            new CMS_Session_Error(CMS_ERROR_COOKIES_DISABLED)
                     );
        }
      }
    }
    return true;    
  }
  
  [..]
}

This method is called statically following CMS_Session::start() on the login page. Since the file serves the welcome page for the CMS as well as login, HTTP_Session::isNew() is tested to allow users with an established session to skip straight out of the method. If the session is new and a session ID can not be detected (all users on first call to the page), the forced redirect will take place with a GET query string. On reloading, if the session ID still can not be detected, the user does not have enabled cookies (the GET query string confirms it is a reload). Therefore, the session can be destroyed and an error displayed to the user - in this example by throwing a CMS_Session_Error.

Note that the built-in SID constant does not need to be passed in the query. Where the session does not persist (cookies disabled) a second session will be created following the redirect. Passing the query simply allows both sessions to be destroyed - Store the (original) session ID from the GET query, destroy the new session, regenerate the old session with the original session ID and destroy that. This is not really necessary, since lingering invalid sessions can be cleared out regularly from the temporary directory or session database using a cron job.

A further extension to HTTP_Session can accomodate applications running on virtual (shared) servers by hash encoding the session data to both scramble the stored information and prevent the packet from being intercepted and changed during tranmission.

function setEnv($var, $val)
{
  $str = $var . "-" . $val;
  $str = base64_encode($str . "," .
                       md5($str . CMS_SESSION_HASH));                    
  HTTP_Session::set($var, $str);       
}

function getEnv($var)
{
  $str = HTTP_Session::get($var);
  $str = base64_decode($str);   
  list($details,$session_hash) = split(",",$str);   
  if (md5($details.CMS_SESSION_HASH) == $session_hash) {
  list($var, $val) = explode("-", $details);
  return $val;
}

This is a simple encoding example that could be used for immutable session data. (For example user login details) A copy of the session variable is retrieved in the get method, to ensure any manipulation is not performed directly on the value of the session variable.

HTTP_Session also offers a range of pre-built functionality including database storage and idle and expiration time management.

Posted on Mar 07, 2004 at 20:49:56. [Comments for PEAR HTTP_Session Package- 1]