The Zend Framework Auth team greatly appreciates your feedback and contributions on our email list: email@example.com
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 browser).
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
Zend_Session_Namespace accessor objects.
Session namespaces provide access to session data using classic namespaces
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
wraps the existing PHP ext/session with an administration and management
interface, as well as providing an API for
Zend_Session_Namespace to 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")
Zend_Auth, the authentication component of Zend
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.
save 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 firstname.lastname@example.org list. A
Zend_Db compatible save handler has been posted to the list.