Re: Auth

> > Well, I did some scratching on that. In my vision, it could be a bunch of > > classes with generic interface(s). Different classes would cover DB-based > > authentication, tokens supplied via standard HTTP auth, storage of auth > > data in session etc. We could team up on the design of this thing. > > It seems there are two pieces needed, something like Auth_Store and Auth_Token. > Both of these should be abstract classes, and any Auth_Store should be able to > work with any Auth_Token (although I can think of a few scenarios where this > wouldn't be the case, but I don't think it breaks the design). > > Auth_Store would be subclassed into SQL, LDAP, File, Htpasswd - any backends > imaginable. Auth_Token would have Cookie, Get, and HTTP subclasses, to think of > a few. You may want to take a look at http://phplib-4.myip.org/ for some recent work that has already been done on this. I am just testing it out now. Also, phplib's Session class and User class are also undergoing active development if you check out the cvs tree at phplib.netuse.de (or the archived newsgroup). The main difference between PHPLIB's approach and what you are suggesting seems to be that PHPLIB's Auth depends on more generic classes to supply the container and session management support. In other words, the Storage and Token support could be used in, say, a Cart class as well. Also Colin Viebrock has developed an Auth.inc class that looks a bit cleaner than the PHPLIB Auth.inc class but which is similiar in many ways to it. My worry in developing a PEAR version of this stuff is that I have no samples to work from showing me how the DB class works (which is the most common way that authentication information is stored). Also, I am not sure how stable the API for the DB classes are - I know there is still some uncertainty about how error reporting should work. How stable is the DB API and are there any samples showing how it works? Regards, Paul Meagher