Forum OpenACS Q&A: user-login/register "service" becoming subsite aware

I've read a few recent threads on the topic of scoping user registrations in the context of 4.6x subsites for one reason or another. For example,

a. to limit user access only to a subsite, solved by using groups and relationships and some pl

b. to identify new users to be added to a subsite (requiring approval), solved by using more pl

c. to match new users to a specific group associated with a subsite, solved using more pl etc.

There's a pattern developing here..

Could/is/will user-login/register be subsite aware for OpenACS 5.x?

Here are a list of some advantages as I see it:

1. Frees developers from having to spend time customizing the RP etc. for each subsite case or OpenACS deployment.

2. New-user and subsite registrations (that need approvals) can automatically be directed to admins scoped to the same subsite. This reduces work load on SiteWide Admins, and helps cases where subsite admins need to search for relevant "needs approval" users which otherwise is quite difficult via the current UI and registration process (as I understand its limitations).

3. Initial logins can (re)direct to default subsite page, or pvt/home if user belongs to more than one separate subsite and is not logging in from within permissible area.

4. The current security "no access" message resulting from access attempts in subsites would change to an appropriate handling based on whatever the subsite user-login parameters are set to.

5. As I understand (experience) it, some of the user-login parameters, such as RegistrationRequiresApprovalP, currently work in MainSite and are ignored in subsites (or dominated by MainSite's settings). Activating these parameters on a subsite level would create all sorts of customizable advantages up to complete user/group segments fully managed at the subsite level.

Also, is this functionality available for 4.63 and I am just missing it?

The tricky part is, if you've set some security settings for registration, such as password expiration, on the main site, and then make registration subsite-aware, anyone with subsite admin can lower the general level of security on the site.

Anyway, what we have done for 5.0 is move a number of the security-related parameters over to acs-kernel, though not all of them, and generally redirect you to the login page of the current subsite to assist with theming.

However, tackling the full problem is out of scope for 5.0.

If you want to push this, I encourage you to talk with Frank Nikolajsen, who has expressed interest in this issue, and put together a more complete proposal, along with drawbacks and security issues, and post that as a TIP for the next release.

Thanks for your suggestion, though.

I'm going to close out the bug until we have a TIP decision. :)

/Lars