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
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?
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.
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.
ZF Home Page
Code Browser
Wiki Dashboard
Would be nice to have a database backend too.