RE: [Fwd: Re: [PEAR-DEV] User authorisation class]

Why not just let the app developer decide? If you have the list of servers then you can pass an array with connection objects references stored in it. The keys in the arrays are the names of the container from the server list. Best regards, Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de > -----Original Message----- > From: Sebastiao Rocha [mailto:rocha@i-node.com.br] > Sent: Saturday, June 22, 2002 7:37 PM > To: pear-dev@lists.php.net > Subject: [Fwd: Re: [PEAR-DEV] User authorisation class] > > Solution tree looks cleaner for sure. You can define a standard interface > for the authentication server, and do the authentication/authorization > work from there. If some else has another kind of authentication service, > He can work on "a driver" for the authentication server, no need to > change the rest. > > As of the overhead, that XMLRPC service can return enough instructions to > you create a authorization objet and save it on the session. That creates > a little problem if you change authorization when a user has an open > session. The new rules only take place after a new session start. > > S. Rocha > > > Sagie Maoz <n0nick@php.net> wrote*: > > > > Markus Wolff wrote: > > > >>1. The user class has a list of servers with their respective login > >> information stored in an XML file. When a user tries to login, the > >> class makes a new connection to each of the servers/containers until > >> a match is found. > >> > >>2. The user class does not do any connections by itself, but you can > >> pass connection objects to it (ie. a PEAR::DB object that already > >> contains an open connection) that are then used in the order they > >> are passed. > >> > >>3. The user class _always_ uses SOAP or XML/RPC to connect to a central > >> authentication server. That server then manages the connection to > >> the true storage containers. > >> > >> > > Just an idea: > > The class has a list of servers as described in solution one. Then, > > when using the class you can pass to it already open connection > > objects as in solution two. > > For every connection object passed, the class uses it instead of the > > next item in the list. If no object was passed, the class would open > > the connection if necessary. > > This would mean of course putting the already used connections (local > > db etc.) on the top of the list. But it solves your problem. > > > > -- > > Best Regards, > > Sagie Maoz > > n0nick@php.net > > > > http://n0nick.dns2go.com/n0where/ ~ Personal mumblings > > http://sodans.sourceforge.net/ ~ Hebrew CMS > > > > > > > > > > > > -- > > PEAR Development Mailing List (http://pear.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > -------- Original Message* -------- > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php