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

Am Sat, 22 Jun 2002 14:36:40 -0300 (BRT) schrieb "Sebastiao Rocha" <rocha@i-node.com.br>: > 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. Storing the user object in a session and only connecting to the data container on login is already implemented, so this is not a problem. The ACL can also be refreshed during a session by calling a readRights() method which reconnects to the container and retrieves the latest ACL information. I guess I´ll go for a combination of solutions 1 and 3: A new connection object will be created for each listet server. That object can also be a SOAP object and will be in most cases. The SOAP server that is connected can in turn be configured to query a list of storage containers. This way you can use the class with or without SOAP. The reason why I choose SOAP over XMLRPC? 1. Currently it´s a buzzword that makes managers go "aaah" and 2. I have more experience with that than with XMLRPC :-) Thanks for your input. However, if anyone else has other ideas, please speak up. Regards, Markus -- *21st Media* | Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff | Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/68879490, Fax: [+49](0)40/68879491