We are currently sharing tables out in array() via $db_prefix. This is our alternative to multisite as we have unique trees of Drupal core + mods + etc on disparate places on disk which are not necessarily persistent given our deployment tools. This allows tables for www.domain.tld (users*, etc) to be referenced by 'child' sites, such as foo.domain.tld or bar.domain.tld, which have the necessary bits stood up in their $db_prefix. We have observed that:
1.) Log into 'parent' site via CAS
2.) Log into 'child' site via CAS
3.) Observe that CAS-obtained session at 'parent' site is no more.
4.) Log into 'parent' site via CAS
5.) Observe that CAS-obtained session at 'child' site is no more.
The same behavior is observed whether you log into the 'child' first as step 1, etc.
We currently run 6.x-1.0 (!) where the bug was first observed. Upgrading to 6.x-2.3 did not seem to resolve the issue.
Our current corpus of tables being shared out for these child sites are as follows:
'actions'
'actions_aid'
'authmap'
'node_type'
'permission'
'profile_fields'
'profile_values'
'role'
'sequences'
'sessions'
'term_access'
'term_access_defaults'
'term_data'
'term_hierarchy'
'term_relation'
'term_synonym'
'trigger_assignments'
'users'
'users_roles'
'users_uid_seq'
'vocabulary'
'vocabulary_node_types'
'workflow_access'
'workflow_scheduled_transition'
'workflow_states'
'workflow_transitions'
'workflow_type_map'
'workflows'
This is kinda, sorta, maybe, possibly inline with observations on http://drupal.org/node/869926
Comments
Comment #1
bfroehle commentedAre you using a method similar to http://www.lullabot.com/articles/drupal-single-sign-across-sub-domains ?
Comment #2
vinmassaro commentedsubscribe
Comment #3
filler commentedSmells like what were doing indeed. We have not been setting cookie_domain per the lullabot URL. When we do that, we find that anon browsings of a second site slay the session of the first. Without setting cookie_domain, only when we try to CAS auth in the second site will the first site's session be slain.
Comment #4
bfroehle commentedWell, it might be the session_destroy() call on line 354 of cas.module. It's no longer present in 6.x-3.x-dev, but I don't remember why it was removed.
You could also try CAS 6.x-3.x-dev which is quite stable, but does change around the data structure. In particular, the {authmap} table is no longer used, in favor of a custom {cas_user} table. [So you'd have to set up your site to share that table as well].
Comment #5
metzlerd commentedDoesn't this sort of make sense, given that you are sharing your session tables? If you are, shouldn't the child be already logged in when you visit it? Or am I missing something here?
Comment #6
bfroehle commentedYes, except that the session cookie might not be shared between the sites. I'd suggest setting that -- then I would think everything would work.
Comment #7
filler commented@bfroehle I figured the destroy was hitting, but I couldnt pinpoint why the user wasnt passable 'good' (referenced in the comments in cas.module, line 352/358 of 6.x-2.3).
@metzlerd I also expected to not have to login per se when hitting sites >= 1 which reference 'parent' tables. However once in via the same CAS TGT, the old session shreds. As do all those less than whats currently exercised. Which is 'weird', prompting my opening the bug.
Comment #8
metzlerd commentedSo the problem I think might be session variables being reset when new session gets created. I'm not sure how wise it is to share the session table, but then not share session cookies.
If you don't set cookie domain, a different session id gets created for each drupal site in the multi-site senario, but then if that's the case, it doesn't make sense to share the session table does it?
Have you considered eliminiating the session table from the list of shared tables, and seeing if that improves the situation?
Comment #9
bfroehle commented@filler: Did you ever get things working?
Also, you'll probably want to upgrade to CAS 6.x-3.x.
Comment #10
bfroehle commentedClosing since there has been no new information since last July.