After fighting with, and losing to, the Single Sign-on module, I discovered what looks like a perfect single sign-on just by sharing the user-related tables and setting the cookie domain in settings.php.
Each of my sites is hosted under its own subdomain of the main site, and they all share a single database. I appended this to the settings.php for all of them:
$db_prefix = array(
'default' => 'pk_',
'users' => 'i1_',
'sessions' => 'i1_',
'authmap' => 'i1_',
'sequences' => 'i1_',
'profile_fields' => 'i1_',
'profile_values' => 'i1_'
);
ini_set('session.cookie_domain', '.industriousone.com');
Here, "i1_" is the prefix for the main site, and "pk_" is the unique prefix for the sub-site. So far, this has been working great. I've been adding content and trying everything I can think of it to break it, but there have been no problems.
Am I missing something? Is it really this easy? And if so, why are modules like Single Sign-On (which is really broken) and Fierce SSO necessary?
Thanks for any feedback on this!
Comments
Thank You Thank You Thank You
I gave up on SSo module as well. Your solution seems to be the most elegant one I have seem so far. Thank you again!
Works only with sub domains?
Well, I tried this idea for my site which has multi sites hosted on the same machine but they are not sub domains of the master site. (They are actual sperate domains such as:
site1.com
site2.com
site3.com
I have been running these multi sites without problem (Except for of course not being able to hold logins across all the sites). Unfortunately, it does not appear this idea works when you are using actual different domains. I am running these on an IIS windows server so who knows, maybe that is the problem and this idea would work on a linix box with different domains. Would be curious if anyone has got this idea to work when it's not sub domains?
-- Dave
I've found the same issue on
I've found the same issue on a multi-site installation without shared logins, on IIS6. The server will drop the authentication when logging into each site, so its a bigger issue that just sharing a table, and obviously sharing a table doesn't stop it from happening.
xtfer.com
platform.sh
yes and no
Yes it is that easy and no that isn't easy unless you are very familiar with databases. This is documented in the handbook in a variety of places.
Those modules exist to fill a need and that need may not actually be yours. Not having used them I cannot say they are broken. By messing with the Drupal tables themselves, you open yourself to odd things and the absolute need to remember and take care with updates and maintenance. This may be a perfectly acceptable risk for you and your teams skill set.
This has been do-able since at least Drupal 4.4 because that's when I tested it :)
A very nice strategy using MySQL 5 is documented here.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Where's the problem?
Can you explain some of those risks? I believe that the solution I suggested takes in to account the information that is in the Handbook. I believe I have configured the shared tables properly.
The SSO module requires shared tables, and so carries the exact same "risk". Except the SSO module breaks site indexing, RSS feeds, and who knows what else.
For future readers, I've been running a family of four sites using this solution since the original posting and so far so good. If it ever bombs I'll come back and report.
updates
Making sure your updates update the correct tables for point releases.
Making sure major release updates still work.
Code changes that may make this approach no longer function with major releases, less risk for bug fix.
New admins who are unaware of the differences of an implementation due to lack of documentation.
I am not saying it's a wrong approach, I am saying there are risks that you generally do not need to be as aware of with most Drupal sites. This has been a possible and documented approach across many Drupal versions now. It just needs to be mentioned that it is generally not for the neophyte and does carry risk if you do not fully understand what you have done.
I experimented with this approach early on out of curiosity which is why I know about it and that it does work.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
What's the risk?
For future readers again, here's the advice to which supeck might have been alluding:
Feel free to add more warnings etc. here. These are all standard Drupal best practices, and things you should be doing whether you are sharing tables or not.
subscribing
subscribing