Skip to end of metadata
Go to start of metadata

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: 7)

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

Labels:
auth auth Delete
cookie cookie Delete
cache cache Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

20 Comments

comments.show.hide

  1. Feb 02, 2008

    Joó Ádám

    Would be nice to have a database backend too.

    1. Feb 02, 2008

      Ben Scholzen

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

  2. Feb 03, 2008

    Shekar Reddy

    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?

    1. Feb 03, 2008

      Ben Scholzen

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

  3. Feb 03, 2008

    Tomas Markauskas

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

    1. Feb 03, 2008

      Ben Scholzen

      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.

      1. Feb 03, 2008

        Tomas Markauskas

        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).

        1. Feb 03, 2008

          Ben Scholzen

          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.

          1. Feb 03, 2008

            Tomas Markauskas

            rememberMe() sets the cookie_lifetime, so the cookies aren't deleted when the browser window is closed, so it's not totally useless. But I agree that not only the cookie_lifetime should be set with the rememberMe method. The lifetime of the session on the serverside is important too.

            1. Feb 03, 2008

              Ben Scholzen

              Yeah, but just setting gc_lifetime is not enough (that is tested by myself).

              1. Feb 03, 2008

                Tomas Markauskas

                I hope you tested it with gc_maxlifetime and not gc_lifetime.

                Well, I had never problems with that. I could imagine, that you didn't specify a session save path, your sessions are stored in /tmp (or c:\temp etc) and some other programs (or other php scripts with bad settings) are deleting the sessions from there.

                I dont see, where this component might be better than Zend_Session, because if you configure it correctly, than nothing else but your application can delete the sessions. And the sessions shouldn't be deleted too early if gc_maxlifetime is big enough.

                1. Feb 03, 2008

                  Simon Mundy

                  This is even more true if you use a DB as a backend - I've been using the DB handler in incubator and it hasn't skipped a beat. I'm not really seeing the benefit of this proposal over existing methods.

                2. Feb 04, 2008

                  Ben Scholzen

                  I tested it with gc_maxlifetime as well as with gc_lifetime.

                3. Feb 09, 2008

                  Joó Ádám

                  I did some search on it, and found a blog post about this issue. The problem with gc_maxlifetime is that by default PHP shares the ini settings, and there are a lot of applications out there that explicitly sets this (often to a small value), so they can overwrite each others needs.

  4. Feb 04, 2008

    David Koblas

    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.)

    1. Feb 04, 2008

      Ben Scholzen

      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.

      1. Feb 04, 2008

        David Koblas

        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.

  5. Jun 23, 2008

    Till Klampaeckel

    Hey,

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

    Till

    1. Aug 01, 2008

      Ben Scholzen

      Currently nothing . . .

  6. Feb 07, 2011

    Dolf Schimmel (Freeaqingme)

    Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.