Core Session Tracking Info

NOTE! The sessioning technology that is part of Zope 2.5 and better is derived from Core Session Tracking, but does not share the same API. If you're using Zope 2.5, you don't actually need to install Core Session Tracking. However, if you've already started to develop using Core Session Tracking and you need your code to run on Zope 2.5, you can install CST on Zope 2.5 without a problem. For new development, the built-in Zope 2.5+ sessioning stuff should be used.

Changes

v 0.1

Initial release

v 0.2

removed dependency on Interface module so the product can be used with released Zope 2.2.X's

v 0.4

session data container as mounted mapping storage. extensive documentation changes. data objects automatically expire without much trouble.

v 0.5

reduced possibility of conflicterrors on writes, use of packless storage for inram data container.

v 0.6

moved dtml files back to product root for compatibility with pre-2.3 Zopes, changed icons, fixed transaction bug in SessionStorage.

v 0.7

fixed kid-clicking bug in RAM-based session data containers. Thanks to Randall Kern.

v 0.8

many expiry-related bugs fixed. Session onStart and onEnd events implemented.

v 0.9

RAM-based session data container fixed, token-related methods fixed. Dependency on Zope.2.3.2+ introduced.

Introduction

This is a development release of the Zope Core Session Tracking implementation. More general information about the design is available from http://dev.zope.org/Wikis/DevSite/Projects/CoreSesssionTracking/FrontPage.

The software allows you to associate "data objects" with anonymous Zope visitors, allowing you to keep state about an anonymous user between requests.

As this is a development release, the API will likely change in a final release.

Features

Core Session Tracking key features:

• Simple RAM-based storage of session data for modest requirements.
• Persistent-object-based storage of session data for permanent-storage or cluster requirements. The storage of session data as a set of persistent Zope objects allows the sessioning implementation to work with a cluster of Zope Enterprise Objects (ZEO) servers.
• Interface-based API. This means it's possible to implement alternate session data managers against things like SQL databases or filesystem stores. The separation of the duties between a "session id manager" a "session data manager" in the design makes the implementation particularly extensible.
• Use of cookies or form variables to pass sessioning information.
• Secure cookie support.

The Big Picture

There are four major components to the CoreSessionTracking design:

• Session Id Manager -- this is the component which determines a remote client's session id. It examines and modifies cookie and form variables to determine or set the client's session id. There may be more than one session id manager in a Zope installation, but commonly there will only be one. Application developers will generally not talk directly to a session id manager. Instead, they will talk to session data managers, which will delegate some calls to a session id manager. Session id managers have "fixed" Zope ids so they can be found via acquisition by session data managers.
• Session Data Manager -- this is the component which is responsible for managing session data. It talks to a session id manager to determine the current session id and creates a new session data object or hands back an existing session data object based on the id. It also has interfaces for encoding a URL with session information and performing other utility functions. Developers will generally use methods of session data managers to obtain session data objects when writing application code. Many session data managers can use one session id manager. Many session data managers can be instantiated on a single Zope installation. Different session data managers can implement different policies related to session data object invalidation and persistence.
• Session Data Container -- this is the component which actually holds information related to sessions. In the initial implementation, it is primarily used to hold special instances called "session data objects". Developers will generally not interact with session data containers. The current implementation defines two types of session data containers: RAM-based and external. RAM-based session data containers are available for use on a per-session-data-manager basis, while "external" session data containers are persistent objects which may be used to store persistent session data objects. External session data containers are traversable, and usually they are meant to be instantiated on a nonundoing database (as accesses to session data containers are very write-intensive).
• Session Data Object -- these are the components which are stored in session data containers and managed by session data managers. Developers interact with a session data object after obtaining one from a session data manager. Session data objects actually store the useful information related to an anonymous user's session. Session data objects can be expired by session data managers.

Prerequisites

versions 0.1 - 0.8 require Zope 2.2.X +

versions 0.9+ require Zope 2.3.2 +

Access to the filesystem which houses the Zope installation.

Manager-level privileges on the Zope installation you wish to install session-tracking on.