The Zend Framework Auth team greatly appreciates your feedback and contributions on our email list: firstname.lastname@example.org
With web applications written using PHP, a session represents a logical,
one-to-one connection between server-side, persistent state data and a particular user agent client (e.g., web
Zend_Session helps manage and preserve session data, a logical complement of cookie
data, across multiple page requests by the same client. Unlike cookie data, session data are not stored on the
client side and are only shared with the client when server-side source code voluntarily makes the data
available in response to a client request. For the purposes of this component and documentation, the term
"session data" refers to the server-side data stored in
Zend_Session, and individually manipulated by
accessor objects. Session namespaces provide access to session data using
implemented logically as named groups of associative arrays, keyed by strings (similar to normal PHP arrays).
Zend_Session_Namespace instances are accessor objects for namespaced slices of
Zend_Session component wraps the existing PHP ext/session with an
administration and management interface, as well as providing an API for
persist session namespaces.
Zend_Session_Namespace provides a standardized, object-oriented
interface for working with namespaces persisted inside PHP's standard session mechanism. Support exists for
both anonymous and authenticated (e.g., "login") session namespaces.
Zend_Auth, the authentication
component of Zend Framework, uses
Zend_Session_Namespace to store some information associated
with authenticated users. Since
Zend_Session uses the normal PHP ext/session functions internally,
all the familiar configuration options and settings apply (see
http://www.php.net/session), with such bonuses as the
convenience of an object-oriented interface and default behavior that provides both best practices and smooth
integration with Zend Framework. Thus, a standard PHP session identifier, whether conveyed by cookie or
within URLs, maintains the association between a client and session state data.
handler does not maintain this association for server clusters under certain conditions because session
data are stored to the filesystem of the server that responded to the request. If a request may be processed by
a different server than the one where the session data are located, then the responding server has no access to
the session data (if they are not available from a networked filesystem). A list of additional, appropriate
save handlers will be provided, when available. Community members are encouraged to suggest and submit save
handlers to the email@example.com list. A
compatible save handler has been posted to the list.