Apache offers you flexible options in implementing session tracking, and there are a number of third-party solutions to which you can have easy access. There are two primary mechanisms for tracking Web sessions: the URL-rewrite method and the cookie method. Each has its strengths and weaknesses, but both are fairly easy to implement. You also have a number of options available in implementation and in addressing security concerns.

Specific Apache session-tracking mechanisms
Depending on which version of Apache you’re running, you have several session-tracking choices available to you. The flexibility offered by each of these options is formidable, so your careful review (and further research beyond this article) is called for:

  • Apache::Session (mod_perl)—This tracking mechanism, which works alongside mod_perl, has several powerful components. These components include an interface that manages the tracking configuration and implementation process; session ID generation with security hash-tag, -type, and -class features in the session database to enhance the handling of session data; as well as coordination of session file-sharing to secure session-tracking data while offering options in log-storage data structures (i.e., you can create a session-tracking database).
  • mod_php—This solution has features similar to Apache::Session, including session ID generation and storage utility. It has the very useful feature of passively implementing URL-rewrite in the event that a client’s browser isn’t enabled for cookies. As with Apache::Session, there are options in data structures for session data storage, including the creation of a session-tracking database.

mod_php session example
The routine here is thorough and elegant. A general session looks like this:

  1. The client makes a request and mod_php looks for a session ID. If there is none, it will try to create a cookie or do a URL rewrite.
  2. A PHP session-handling routine allows the server administrator to set up specific variables for storage as session-tracking data elements; when any Web site feature is accessed (i.e., when anything on a Web page is clicked), all variables that aren’t empty are stored in a flat file named after the session.
  3. On subsequent calls to that particular Web page feature by the same user, the previously stored values are immediately referenced and can be used by the code submitted to the browser for dynamic, user-specific page features.

Now that’s really cool stuff. With such a mechanism in place, the user’s experience on your Web page can be extremely customized, and dynamically as close to real time as HTTP is able to get! The configurability of mod_php is extensive by modifying the file php.ini. The parameters available to you (you’ll see them in the file prefixed with the session) include:

  • Forcing cookies for session ID storage
  • Naming the cookie, setting its maximum lifetime, domain, and path
  • Filenames and directories for session storage
  • URL formatting
  • Caching options
  • An anti-hijacking feature to confound URL theft

If you’re using Apache 1.3.x, you can use the mod_session module for session-tracking implementation. Like mod_php, this module will not allow a client request to pass without the assignment of a session ID. The handling of session tracking data, however, isn’t facilitated by the module. You have to handle it with separate software.

Another thing mod_session can do, however, is redirect incoming requests to specific entry points. It is often the case that a Web site may have a multitude of pages and that many are directly accessible at the start of a client session (i.e., the user need not visit the home page in order to access a subsequent page). With mod_session, you’re able to control the client’s entry point(s) into a Web site, forcing authentication if desired.

Finally, mod_session shares with the modules above the capacity to implement cookies or URL rewrite as needed to ensure the persistence of session tracking.

Here’s what mod_session does:

  1. Incoming requests from clients are immediately checked to see if the request matches an acceptable Web site point-of-entry; the client will be redirected to a specific entry point if there isn’t a match.
  2. A unique session ID is generated.
  3. mod_session will attempt both cookies and URL rewrite (the module itself does not do URL rewrite—it is performed by a separate script).
  4. When a subsequent request from the client arrives, both the HTTP URL and cookie are checked for session data; the module will go with whichever medium the client is using for sending session data.


Be sure to list the module before mod_browser and mod_usertrack in Apache’s configuration file.

Like mod_php, mod_session empowers you with a number of useful configuration options, some of which include:

  • Turning cookies on or off
  • Specifying cookie name, domain, path, and expiration date (as with mod_php)
  • Embedding session names in rewritten URLs
  • Noting URL time duration for validity of embedded session ID
  • Specifying a default URL for a site entry point
  • Creating a list of additional valid site entry points
  • Specifying the location of scripts for URL rewriting

Know your users
While there is an increased security risk with the use of session tracking, there is a trade-off in additional security features. If you chart both sides of the problem, you’ll find that the disadvantages cancel out, and in any case you can easily undertake additional measures to offset your risk. Beyond this, there is tremendous benefit in better understanding how your Web site is being used by your users. And the benefit of knowing your users, and fine-tuning your system to better serve them, is the single greatest advantage an administrator can pursue.