Re: Re: AUTH & LiveUser

<I forgot to include the list adress in my reply, so here it comes again> On Wed, 06 Nov 2002 17:48:26 +0100 "Stijn de Reede \(SJR\)" <sjr@gmx.co.uk> wrote: > I'm in the same situation as you are. I'm rebuilding my Shop System, and > planning to use PEAR. I've already played around a bit with DB, > DB_DataObject and HTML_Template_Flexy, and so far I really like it. > However there must also be a (simple) login feature on the site. > My requirements: > - login, logout > - remember login by session (and maybe cookie) > - 2 types of persons: Users and Admins > - Right management: just assigning rights to Admins should be enough, > but assigning rights to Groups and/or Admins could be useful too. > > Undoubtly LiveUser can do this all, and much more. However, it hasn't > been updated in a while, or even well documented (which seems te be the > problem with a lot of pear packages; this is familiar to me, writing > docs isn't a lot of fun ;)). Well, I guess I´m the one to blame for the lack of documentation, even though normally I´m a militant documentation fetishist ;-) I simply don´t have the time ATM which is also one part of the reason why there´s no simpler rights container yet - the other part is that we have not yet decided whether it´s a good idea to do a simpler version using the same database model (so you´d have an easy upgrade path) or just wrapping an easier API around the same model. > Right now I'm thinking I might implement my own simple Right management, > just by letting the User class extend the DataObject class, and putting > in some extra functions to check Rights. Just a simple 2 table scheme: > admins & rights, with a 1-to-n mapping (and separately the user table, > with nog Rights mapped to it). As a matter of fact, Liveuser was designed to leave you exactly this freedom. You can implement your own authorization and rights management containers that can use any database or other storage model that you desire. All you have to do is extend the container base classes and keep the names, parameters and return values of the public methods as they are. Internally, your classes can do whatever they want. You can then use the LoginManager to manage login/logout activities and to query rights. The advantage is, that you´ll always use the same basic API in all other scripts/classes of your projects - but should you ever need another type of authentication or authorization, you can simply switch the corresponding container classes in the LoginManager config. Btw. don´t be shocked when you look at the number of methods in the rights container - you don´t need to implement all of them. You only need to implement those that are really used by the LoginManager. We´re thinking about moving the admin functions to a separate class to avoid confusion and cut off parse time for functions that are seldomly needed. Regards, Markus -- Markus Wolff <wolff@21st.de>