[support] unified login for multiple domains

[Joe Murray]

You have to share a database if you want to share login users / roles, etc.
You should change 
'default' => 'tld_',
for each of the third level domains to:
'default' => 'tld1_',
...
'default' => 'tldn_',
In order for all of the non-shared drupal tables to be unique for each third
level domain (this will give you different content for each site).

There are further possible complications if you are using CiviCRM. It sounds
like you may only need one instance of CiviCRM, but more likely you want
several sites to all use CiviCRM and have a shared CiviCRM database.

See
http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+for+Drupal+-+Configur
e+Multi-site+Installations for more info - it may be slightly dated in some
details at this point but the general ideas remain the same.

> Message: 1
> Date: Fri, 8 Dec 2006 19:25:28 -0800
> From: Hugh Esco <he at reclaimedcomputers.ca>
> Subject: [support] unified login for multiple domains
> To: support at drupal.org
> Message-ID: <20061208192528.7b2d9a15.he at reclaimedcomputers.ca>
> Content-Type: text/plain; charset=US-ASCII
> 
> I've been reading through forum threads on the drupal site 
> (mostly a year or two old), trying to piece together how it 
> is I would provide for a single unified login that would 
> permit folks to interlink between multiple instances of 
> drupal at a handful of third level domains providing 
> different services to the volunteers and members of an 
> organization as well as the folks they attract to their public site.  
> 
> I'd be happy to draft a Handbook page on the subject if I 
> could get some clarification and direction from those who 
> have plowed this row before. 
> 
> One of these sites hosts civicrm and serves as a back office 
> application server to support distributed volunteers working 
> together.  Another will be a members site, plus a blog, plus 
> perhaps another public site.  
> 
> What I've figured out so far, is summed up with:
> 
> in each sites/tld.ourdomain.org/settings.php
> ini_set('session.cookie_domain', 'ourdomain.org');
> 
>  *   $db_prefix = array(
>  *     'default'   => 'tld_',
>  *     'users'     => 'shared_',
>  *     'sessions'  => 'shared_',
>  *     'role'      => 'shared_',
>  *     'authmap'   => 'shared_',
>  *     'sequences' => 'shared_',
>  *   );
> 
> And here is where I'm guessing to bridge it all together, 
> creating VIEWs for each of those shared_ tables which looks 
> instead at a single user table; at which domain or database, 
> I;m not sure.  
> 
> We want to collect that data in our crm instance, but I'd 
> prefer not to expose that to the public.  
> 
> I want someone who has logged in to www. or blog. to not face 
> an additional log in when they look at members. or crm, but 
> to be turned away if their user shouldn't be on those sites.  
> 
> I thought I'd outline this here and ask for feedback on this 
> general approach before getting lost in a trial by error 
> forced march.  Has anyone who has done this before know how 
> to best proceed here?  Am I on the right track with the sql 
> views?  I'd certainly apreciate some direction.  
> 
> Thanks,
> -- Hugh Esco
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 8 Dec 2006 19:34:27 -0800
> From: Hugh Esco <he at reclaimedcomputers.ca>
> Subject: Re: [support] unified login for multiple domains
> To: support at drupal.org
> Message-ID: <20061208193427.23bdeb56.he at reclaimedcomputers.ca>
> Content-Type: text/plain; charset=US-ASCII
> 
> Sorry, one additional wrinkle I guess I should have mentioned here.  I
> want to provide a distinct database  for each of these sites.  -- HE 
> 
> On Fri, 8 Dec 2006 19:25:28 -0800
> Hugh Esco <he at reclaimedcomputers.ca> wrote:
> 
> > I've been reading through forum threads on the drupal site (mostly a
> > year or two old), trying to piece together how it is I would provide
> > for a single unified login that would permit folks to interlink
> > between multiple instances of drupal at a handful of third level
> > domains providing different services to the volunteers and 
> members of
> > an organization as well as the folks they attract to their public
> > site.  
> > 
> > I'd be happy to draft a Handbook page on the subject if I could get
> > some clarification and direction from those who have plowed this row
> > before. 
> > 
> > One of these sites hosts civicrm and serves as a back office
> > application server to support distributed volunteers 
> working together.
> >  Another will
> > be a members site, plus a blog, plus perhaps another public site.  
> > 
> > What I've figured out so far, is summed up with:
> > 
> > in each sites/tld.ourdomain.org/settings.php
> > ini_set('session.cookie_domain', 'ourdomain.org');
> > 
> >  *   $db_prefix = array(
> >  *     'default'   => 'tld_',
> >  *     'users'     => 'shared_',
> >  *     'sessions'  => 'shared_',
> >  *     'role'      => 'shared_',
> >  *     'authmap'   => 'shared_',
> >  *     'sequences' => 'shared_',
> >  *   );
> > 
> > And here is where I'm guessing to bridge it all together, creating
> > VIEWs for each of those shared_ tables which looks instead 
> at a single
> > user table; at which domain or database, I;m not sure.  
> > 
> > We want to collect that data in our crm instance, but I'd prefer not
> > to expose that to the public.  
> > 
> > I want someone who has logged in to www. or blog. to not face an
> > additional log in when they look at members. or crm, but to 
> be turned
> > away if their user shouldn't be on those sites.  
> > 
> > I thought I'd outline this here and ask for feedback on this general
> > approach before getting lost in a trial by error forced march.  Has
> > anyone who has done this before know how to best proceed here?  Am I
> > on the right track with the sql views?  I'd certainly apreciate some
> > direction.  
> > 
> > Thanks, 
> > -- Hugh Esco
> > -- 
> > [ Drupal support list | http://lists.drupal.org/ ]
> 
> 
> ------------------------------
> 
> -- 
> [ Drupal support list | http://list.drupal.org/ ]
> 
> End of support Digest, Vol 48, Issue 12
> ***************************************
>