Re: New Package Proposal: Enterprise A&A

On Wed, 15 Jan 2003 13:06:30 -0600 (CST) Tony Bibbs <tony@tonybibbs.com> wrote: > Man, that opened a can of worms for me. Here are more thoughts: > > On Wed, 15 Jan 2003, Arnaud Limbourg wrote: > > > If everybody agrees on keeping one package it does not really matter, > > it is more an API question for people already using it. > > Good question. My thoughts here are maybe the answer is we branch > LiveUser so you can continue using it to scratch your itch. Then we can > work on an approach together and then worry about API issues when it is > time to merge back into the LiveUser project. Or maybe live user goes > away after we complete our merge and get things stable...if supporting as > much of the original live user API is a requiremene we come up with I"m > fine with that...it would minimize the impact users of LiveUser when they > go to upgrade. Just a thought: As LiveUser´s LoginManager class is the only one that is used directly by the end user, it already is kind of a wrapper for the container (provider) classes - my guess is, it should be pretty easy to integrate the A&A providers into that wrapper, so the LiveUser users could benefit from the new containers/providers quite quickly (aaargh, no matter what we do, the first thing we should do is find a common naming scheme for containers/providers/drivers... this drives me nuts :-)). Does A&A have a similar class? Here´s in short what the LoginManager does: - Handling the login/logout process (user can choose if he wants to redirect to a central page if the user is not logged in or logs out, or if a user-defined callback function will be called) - Can use a list of containers that will be queried on login in case user data can reside in more than one place (i.e. search in local database first, if the user wasn´t found then query LDAP server, then query some exotic server in a galaxy far, far away using SOAP or the like...) - Can be configured to use any permission system by including a simple container class - Takes care of user/permission object persistance in sessions - Checks if the used containers support certain functions and downgrades gracefully if they don´t - Fully configurable behaviour via XML config files or PHP arrays from any other source ...and some smaller features... If A&A doesn´t have such a class, this could be the basis for a common wrapper around both approaches. Also, does A&A have a common API for administration functions across its providers (i.e. create user, update user data, set user rights, set group membership etc.)... LiveUser has this, but currently all admin functions are included in the respective container class, which is a lot of parsing overhead when they´re not needed (about 95% of the time). So splitting the containers in one common and one admin version is something that yet has to be done. > My needs for an A&A system aren't immediate. As long as I know what the > service API is and what the user object will look like, we (Geeklog > Developers) can stub out dummy functions that let us continue with other > tasks. Personally I wouldn't mind moving all my XML-RPC stuff over to > SOAP (SOAP is a core competency I have now) and taking the best of both > worlds. A ground-up effort could still 'borrow' code from both packages > making getting an alpha release up in short order possible. If there will > be one or two other heads to throw at this, that sounds quite agreeable to > me. SOAP and LDAP certainly are two things I always wanted to see in LiveUser, so I see lots of merging potential here. However, my need for such a system is very immediate. Actually, I am in the process of writing end user docs. A complete administration GUI is to be written very soon as we need it for our current project - and quickly, that is. I intended to make that GUI available as an open source project as well, but it will also be the base of all our commercial applications that we plan to torture people with very soon ;-) So I´m under a little pressure to get this thing resolved somehow as nobody likes to develop against moving targets - BC definitely is a huge issue for me. Regards, Markus -- Markus Wolff <wolff@21st.de>