On Thu, Jun 20, 2002 at 03:11:13PM -0400, Nathan Valentine wrote:
here is the $64,000 question. Say you have users from BigCo. Who will be administering these users. Are you going to do it? If so, I would strongly consider exUserFolder.
Does a untrusted administrator at BigCo administer their users? Or worse, does BigCo make all or part of their content available to LittleCo? Do alliances shift like Afghani politics? In that case, none of the stock folders will do it for you.
Several BigCo employees will have free run over the entire site including all BigCo client 'portal data'. The client portal data is pretty much just push-mode. They(clients) shouldn't really be able to make any changes. It's just there for them to look at. Down the road, perhaps it would be nice to be able to delegate to a person at each BigCo client the authority to create new users within their client portal, but that's not currently a major design consideration. Oh, and of course a BigCo client can view only their own portal.
That's your main problem -- the down the road problem. If it is truly not a major concern, go with exUserFolder. More mature, battle tested, etc. exUserFolder will let the administrator(s) attach arbitrary data to users. You could certainly attach a company property. This would seem sufficient unto your present needs. The main difference(s) between my user folder (deUserFolder) and exUserFolder are: 1) I have tested only a postgres backend, exUserFolder has multiple backends. 2) deUserFolder has a notion of "affiliation list", which may be "unrestricted", or a finite list of names. An administrator can belong to one or more affiliations. He may then administer users who have a subset of his affiliations. I am not doing content management; this is purely to get me out of the overhead of administering _many_ users, and the potential legal problems of inadvertant disclosure. (Suppose an employee quits and goes to work for a competitor, but is able to access his previous employee's data, and this causes harm. Who is responsible?) Really, the primary difference in strategy between deUserFolder and exUserFolder is the experiment of creating limited user administrators. Content administration is a different problem, and I have not thought about that enough to tell you if the deUserFolder approach is even remotely useful. I suspect permitting remote content administration would NOT be covered well by what I have done. Also, note: there is yet another approach. You can use ANY user folder if BigCo's userfolder is contained within BigCo's portal. That is, if you have a BigCo folder, and a BigCo userfolder within it, you know by virtue of his URL that he has been authenticated against a BigCo userfolder. Have your actual programs in yet another folder, and use a portable hole in the BigCo folder pointing to the real (shared) programs. If you are worried about fewer than a couple hundred BigCo's, and bigCo's don't want transitive access; this can be quite compelling. Jim
My intention is that the client name will determine the database and/or tables that the portal data is pulled from and the username and password will be used to authorize access to the data in the database/tables.
-- --- Nathan Valentine - nathan@nathanvalentine.org Jabber: NRVesKY AIM: NRVesKY ICQ: 39023424