Last active
March 14, 2024 13:28
-
-
Save omega8cc/5724528 to your computer and use it in GitHub Desktop.
Steps to implement (pseudo) Single Sign-On (SSO) for any set of sub-sites on BOA
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Steps to implement (pseudo) Single Sign-On (SSO) for any set of sub-sites on BOA: | |
1. Add domains and even wildcard *.sub.domains as aliases to your site in Aegir | |
2. Install and configure Domain Access -- https://drupal.org/project/domain | |
3. Set 'server_name_cookie_domain = TRUE' in the modules/boa_site_control.ini file | |
Done! | |
How it works? | |
The special INI variable will force $cookie_domain to always match and use | |
SERVER_NAME, so foo.com in this example, to avoid using default HTTP_HOST. | |
This allows you to stay logged in, no matter which sub-site managed via | |
Domain Access you visit - as long as the site uses any sub.foo.com subdomain | |
in the same foo.com suffix as its main domain/URL. | |
Note: You don't need to add anything in local.settings.php for Domain Access. | |
Just make sure to upload it as sites/all/modules/domain - it will work | |
out of the box! | |
Note: The special INI variable only automates setting correct, wildcard $cookie_domain | |
but it will not offer *real* SSO, because it would require patching Drupal core. | |
You will be able to access any sub-site configured in Domain Access with sub.foo.com | |
or bar.foo.com as its *main* domain without the need to re-login, because | |
the $cookie_domain will be always automatically set to .foo.com. You can add | |
other domains, including bar-domain.org, as aliases to any sub-site configured | |
in the Domain Access, but you will stay logged in only when visiting main | |
domains configured for each sub-site, as long as they share the same suffix. | |
Note: If you are familiar with Domain Access module, then it is probably obvious, | |
but since the first version of this how-to apparently caused some confusion, | |
let's make it crystal clear on how it is expected to be configured: | |
1. The main site domain configured in Domain Access must match the main name of | |
this site used in Aegir, because it will be used via SERVER_NAME header | |
in the automated configuration of $cookie_domain, on the fly. | |
2. All sub-sites configured in Domain Access must use sub-domains in the main site | |
name, configured in step 1 above. | |
3. You can't configure foo.domain.com as a main site and then use bar.domain.com | |
subdomains for sub-sites. In this case sub-sites should use subdomains in the | |
form of: bar1.foo.domain.com, bar2.foo.domain.com, bar2.foo.domain.com etc. | |
4. You can add any domains and any subdomains as aliases to any sub-site, | |
so these sub-sites will be accessible also via their own domains or sudomains | |
not sharing the same suffix, but you will stay logged in only when accessing | |
those sites via their sub-domains sharing the same suffix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment