Infinite redirection with clean vanilla Domain Access and Shared Sign-on
| Project: | Shared Sign-On |
| Version: | 5.x-1.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
I enabled the Shared Sign-on 5.x-1.3 module on a clean Domain Access 5.x-1.4 installation and immediately ran into this problem of infinite redirection: http://drupal.org/node/147445.
I used out-of-the-box vanilla Shared Sign-on with a basic Domain Access setup with two main domains foo.com and bar.com and several *.foo.com subdomains. No table prefixing is used because ALL my tables are shared between all domains *.foo.com and *.bar.com. I checked the "Synchronize with Domain Access" checkbox in the Shared Sign-on config page. The master domain got set automatically and correctly to http://foo.com. However, when I visit bar.com, it goes into an infinite loop of redirection between foo.com and bar.com. In my vanilla Domain Access settings, I have a single settings.php file in sites/default/ and $cookie_domain is set to "foo.com". All *.foo.com domains work perfectly (with single user sign-on as expected) with or without the Shared Sign-on module.
#1
Hmm. Since I don't have a lot of time to sink into this at the moment, I'd appreciate it if you'd try the thing that solved the problems of the user convulsion...
http://drupal.org/node/285319
...and if it works for you, I can update the SSO page so that this is on the front page.
#2
Thanks for your response.
I read convulsion's thread already. Setting $cookie_domain to the base domain foo.com to get single sign-on for all *.foo.com domains is well documented in Domain Access and it works perfectly without any need for a SSO module.
The problem is that setting $cookie_domain to foo.com eliminates all possibility of logging into any *.bar.com domains since cookies are not valid (internet standard) across multiple second level domains (even though Domain Access does not stop you from creating multiple second level domains such as foo.com and bar.com in the same Domain Access install).
So I guess to be really useful, SSO needs to focus on making single sign-on possible across all domains hosted on the same Drupal installation including domains hosted under Domain Access.