Forum OpenACS Q&A: Subsites & Separate Users

Collapse
1: Subsites & Separate Users
Posted by James Thornton on 03/15/04 06:35 AM
A Collaboraid developer blog entry entitled (Sub)sites and spaces discusses separating users so that a registered user of one subsite does not imply that he/she is a registered user of another subsite.

Has anyone implemented such a system?

Collapse
2: Re: Subsites & Separate Users (response to 1)
Posted by Windell Dubois on 03/15/04 08:05 PM
I havent heard of something like that being implemented so far, but it would be a great idea.  I believe that if done correctly, it would allow the creation of multiple independent websites within a single OpenACS instance without the member sorting difficulties.  Just to maintain the original purpose of this thread, has anyone implemented such a system?
Collapse
3: Re: Subsites & Separate Users (response to 2)
Posted by Guan Yang on 03/15/04 09:43 PM

I've implemented such a system for ACS 3.4 (Oracle). My approach was simply to create a sites table (with a separate table for mapping hostnames to sites).

I then added the site_id column to a number of key tables, notable users. (ACS 3.4 doesn't have an acs_objects table or a similar mechanism.) Plus a bunch of UI to create and manage the sites, changes to the request processor to set ad_conn site_id, and the removal or changes of some unique contraints, e.g. on users.email (this would be parties.email in OpenACS).

It wasn't the most challenging thing I've accomplished, but it does require some significant changes in the request processor that were sometimes difficult to debug.

All of this was done for an app where we wanted to run a real ASP, i.e. with hundreds of sites.

Collapse
4: Re: Subsites & Separate Users (response to 1)
Posted by James Thornton on 03/16/04 12:32 AM
What about simply including the package_id in the parties table, and setting a unique constraint for (email,package_id)? Then you could set a flag in a subsite table (haven't looked into which one) indicating if it should inherit users from the parent site.
Collapse
5: Re: Subsites & Separate Users (response to 1)
Posted by Dave Bauer on 03/16/04 12:45 AM
Hmmm,

This should "just work"

An application group should be assigned to each subsite. The application group for the Main Subsite should be registered users.

So to create several subsites you should be able to make them all subsites of Main Subsite. All users will be members of the main subsite. This isn't really a problem, you could set that up as an administrative site. You wouldn't advertise the URL as one for people to visit or register.

I don't see any need to create more layers when the existing tools in OpenACS can support this use.

If a package doesn't honor these settings, it should be fixed. I think it is reasonable for packages to refer to their parent subsite instead of assuming Registered Users and Main Subsite.

Collapse
6: Re: Subsites & Separate Users (response to 1)
Posted by James Thornton on 03/16/04 12:56 AM
My goal is to make users completely unaware of the main site.

Suppose that each subsite is for a separate company and you are acting as an ASP. It's possible that a user would try and register with more than one company so if he/she uses a different password to register with the second company, the system would say "invalid password" or "account already exists".

Collapse
7: Re: Subsites & Separate Users (response to 1)
Posted by Dave Bauer on 03/16/04 01:04 AM
James,

Of course. My mistake.

Well, OpenACS (ACS 4 really) wasn't designed to do this, now I see why the jumping through hoops is necessary.

I wonder if this is a goal for OpenACS to support. Probably not in the short term, it will require a well thought out design if this type of support can be put into the tookit.

Let the discussion continue! :)