Added by Ben Scholzen, last edited by Ben Scholzen on Feb 04, 2008  (view change)

Labels

 

Zend Framework: Zend_Auth_Storage_Cookie Component Proposal

Proposed Component Name Zend_Auth_Storage_Cookie
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Auth_Storage_Cookie
Proposers Ben Scholzen
Revision 1.1 - 2 February 2008: Initial proposal. (wiki revision: 6)

Table of Contents

1. Overview

Zend_Auth_Storage_Cookie is designed to be a persistent alternative to Zend_Auth_Storage_Session. Utilizing good design, the client side cookie will only consist of a unique id, with the server side storing a Zend_Cache object containing the matching unique id in addition to the auth information. Besides the obvious security advantages to this approach we avoid any issues of size limits of cookies. Most importantly, this method allows the programmer to decide when the auth storage is no longer need and avoids the current situations where PHP determines the life of sessions.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will not save any data except an unique id in the user's cookie.
  • This component will store everything in a pre-defined Zend_Cache object.

4. Dependencies on Other Framework Components

  • Zend_Auth_Storage_Interface
  • Zend_Cache

5. Theory of Operation

The coder will first instantiate a new Zend_Cache Object, which is the supplied to the constructor of Zend_Auth_Storage_Cookie. This can then be supplied as storage to the Zend_Auth object.

6. Milestones / Tasks

  • Milestone 1: Component is approved.
  • Milestone 2: Working prototype checked into the incubator.
  • Milestone 3: Unit tests exist, work, and are checked into SVN.
  • Milestone 4: Initial documentation exists.

7. Class Index

  • Zend_Auth_Storage_Cookie

8. Use Cases

UC-01

9. Class Skeletons

Would be nice to have a database backend too.

Well that's up to you, just use a Zend_Cache Backend for your database.

There are some articles that recommend NOT to use memcache as a savehandler because if it runs out of memory for the memcached daemon, some of the old session data might end up getting garbage collected (FIFO). Memcache can potentially expire old IDs (FIFO) when there is no more room to store new ones. So, when using memcache for cache-backend, how does this class ensure integrity of auth-cookie data and that is it not already garbage-collected by memcache?

Oh, in that case i would suggest that this class does simply not allow memcache as a savehandler, would that be okay?

Could you explain, what would be a case, when PHP decides that a session is no longer needed?

Well, one reason could be, when the webserver is restarted. Well and the other ones I don't know. Even if I put up all limits, a session does not last longer than an hours.

You can set a different session save path or use a database and your sessions won't be deleted after a restart.

I have never seen any problems with sessions lasting for several months or more. You just have to adjust the settings if you want the data and cookies not to be deleted (gc_maxlifetime, cookie_lifetime and save_path).

In that case, the documentation of Zend_Auth_Storage_Session should be extended, to let the user know that a call to Zend_Session::rememberMe(); is not enough, but needs additional action by the application, or those things should be done by rememberMe() itself. So far I consider this method as useless.

View the rest of this thread. Most recent comment: Feb 09, 2008
6 more comments by: Ben Scholzen, Simon Mundy, Tomas Markauskas, Joó Ádám

This is interesting, but I would look to having a cookie based authentication that isn't tied to a storage. In general when I do cookie based authentication it's done via a private signing system. So I can do something simple like:

// where $rand == random number
// $uid == user identifier
// $key == key stored in the cookie

if (substr(md5($rand . $uid . self::SECRET), 0, 16) !== $key) {
return false;
}

This means that you can do an authentication without involving any storage subsystems. You then of course can choose what to do with your user identifier – that may involve a DB/Cache lookup... But, you've at least established the credential without any lookups.

You can also add all sorts of useful information to the cookie, like issue timestamps and other things that you can use to create tiered authentication (write permission is good for 2 hours after login etc.etc.)

Well, that does sadly not fit in the current concept of Zend_Auth. It is tied to a storage system, either to just store the identity itself or some more information about it.

In this instance we're storing the identity in the cookie. We just don't need the support of a backend system for validation.

The current proposal requires Zend_Cache for validation, as opposed to using a SECRET for computing and validating checksums.

Hey,

what's the status on this proposal? I am curious, because I'd like to use this code.

Till

Currently nothing . . .