Sharing members' login data

This is a message to all those who have been asking themselves: What will
happen it the world out there wants to become a member of one of our new
Plone-based sites - say, on srichinmoy.org - and then they go to
srichinmoyraces.org or any other of our dozens or hundreds of sites, and
they want to be members of those, too - will they have to join each of these
sites individually, or is it possible to create an architecture such that
once they joined one site, they automatically joined all of them?

That would be nice. But then, what happens to the member folders where they
can leave their wonderful comments about us? Let us say someone puts a
comment about a race - on srichinmoyraces.org - then we wouldn't really
appreciate to see this comment popping up on srichinmoylibrary.org.

So, what we are looking for is an architecture that follows the paradigm
"membership - globally, member folders - locally".

Fortunately, there is a straightforward solution. When you create a new
Plone site, you are given the choice between the two options "Create a new
user folder in the portal" or "I have an existing user folder and want to
use that instead". While the first choice is the natural one under normal
circumstances, in our case we would select the second one. (Actually,
deleting the acl_users inside a Plone site later on gives the same result -
as I just checked on my http://www.vasudevaserver.org:7091/Dhyani which I
mention because there were already some faithful members there, who are now
gone with the wind.) - Now, what happens is that the Plone site inherits the
next acl_users that it can find on the acquisition path, as can be checked
on Jagrata's new architecure where the Plone sites are not the direct
children of the root, but of /home or /pub, respectively. The obvious
architecture would be to have only one acl_users - either at the root or
inside /pub (for the public) or inside /home (for us guys).

And of course, Plone will create a fresh Member folder for these users
inside the current Plone site (on first-log-in-time, not on join-time,
because there is no join-time for 99% of the sites!) This is not unexpected,
since a Plone site doesn't really have a chance to know about those other
Member folders in those other Plone sites, because a Plone site never really
knows anything about other Plone sites - a Plone site is a Universe.

Unfortunately, the world is a complicated place at times (as we know from
Calvin and Hobbes). This global acl_users would work for all the Plone sites
underneath, BUT: it would not be a Plone-acl_users file, but a
Zope-acl_users file. What are the consequences?

1. The good news is that the roles that are not part of the default
Zope-users-system (like reviewer, editor - Zope thinks only in terms of
manager, owner etc.) can be added on the Zope-level. They don't make a lot
of sense there, but Plone inherits them and Plone does understand their
significance. What I mean is that when a user is a reviewer on the
Zope-level, which doesn't mean anything to Zope, then he is also a reviewer
on the Plone-level, because Plone inherits the user properties from Zope's
acl_users, and Plone understands "reviewer" as "someone who is a Plone
reviewer", which is a very good thing.

2. The not-so-good-news is that we are losing the Group-aware-User-Folder
stuff, since that is a Plone feature and not a Zope feature. Maybe I can
comfort Priyadarshan here a little by mentioning that we could have a
different architecture for us (developers, editors etc.) and the public,
using Plone's user system for us and Zope's user system only for the public,
since it is the public's membership issue that we concerned with anyway, and
who wants to put them into different groups?
- By the way, if anybody thinks he's just got a very smart idea: why don't
we put all our Plone sites into one big Parent-Plone-Site, with the Parent
containing an acl_users file (which would then automatically be a
Plone-based Group-aware-User-Folder-acl_users file) and which would be the
one that all the children Plone sites inherit from, ---- forget it. Doesn't
work.

3. Now, what happens to our added member properties (the gender-stuff)? If
Plone loses its acl_users, will the new properties - which are definitely
Plone-customizations and unknown on the Zope-level - get lost as well? Good
news again - they don't get lost. Plone basically says, "I know you are a
member because your name is in Zope's stupid little acl_users, but I know a
lot more about you because I saved it in my own memberdata_tool".

Discussion:

Jagrata:
This means that a Member would have the same roles in all sites: those assigned in Zope's acl_users, right? Or can we override this on the site level?

Priyadarshan:
That is an essential point. We do not want to lose the GRUF usability. I do believe GRUF is usable outside Plone. Also, a person who is a reviewer 
on one site, maybe is just a regular member on another site. Common login should not automatically indicate common roles among sites.

My response:
My idea was to have only the world out there as Members of Zope's parent acl_users, and they would indeed have the same role on all sites, which
means they would be Authenticated Users on all sites. All of us, however, would be users on the Plone Site level. Thus, someone could be a  reviewer on one site, an editor on another and an ordinary Member on all other sites, etc. etc.
GRUF does not take place outside of a Plone Site. But this fine-grained membership logic seems to me only necessary for us guys (editors, 
reviewers etc.) and not for the public users, who will be treated all equally, having the right to see content and maybe make some comments, save their 
favorites and so on. So if this philosophy of mine is correct, then this approach (as described in my previous How-To) is applicable.

Jagrata:
Ok. Site Administrators, Editors, Designers in the individual Plone Site acl_users. Members and Anonymous Users in Zope's acl_users in the root  of the public Zope instance(s) filestorage. Let's assume that a Member is known in Zope's acl_users. If that Member logs in to srichinmoy.org, and then points his browser to srichinmoyraces.org, does he have to log in again?

Priyadarshan:
Common login means that I have same login and same password. If the session is based on the domain name, I would have to relogin if i type the address in the bar. But maybe using cookies this can be avoided. Cookies can be shared by many sites.

My response:
No! Let us assume that you are logged in to srichinmoy.org and there, you click on a link to srichinmoyraces.org, then you are automatically  logged in there, too! (I tried it.) At this point, Plone is smart (don't forget that we are still living inside the same Zope instance), and we don't have  to use cookies.

Jagrata (concerning member properties like "gender"):
So when I join srichinmoy.org, my "gender" is not understood by srichinmoyraces.org, right? It seems that I would have to establish my
"gender" separately for all my sites in the set.

My response:
You are right. These properties are defined on the Plone-Site-level, so one might even define different properties for different sites, and  naturally the different sites don't know about the properties on other sites. This might even make sense for us. On certain sites, we might want to take a more "personal approach", asking people all kinds of things about them,  while on other sites, me might want them to be able to keep their privacy.