The frameworks support two different methods for sharing sessions between subsites, allowing a user logged in via one subsite to remain logged in when they visit another.
This feature isn't something that needs to be configured, it happens automatically. It is primarily intended to support Assisted Service users who might log in on a staff subsite, but need to assist a user on a public website in the same iCM installation.
The sequence of events is:
- A user is logged in on Subsite A
- The user follows a link to an article on Subsite B - this must be a link iCM "knows" about, ie a related article, article inline, or an article picked via an asset picker in an extra tab. Links embedded directly will not transfer sessions
- The user is now logged into Subsite B
- A cookie is set for the Subsite B domain which has the same session ID as the one previously set for Subsite A
Note that all of the usual iCM and site security features still apply. A user navigating from one site to the other would still have to be in the relevant security groups to access content and have access to the relevant subsite zones.
Note that this feature shouldn't be used now that the session transfer behaviour described above is available. In time it will be officially deprecated.
A single enterprise iCM installation will often power multiple subsites. When these subsites are accessed on different subdomains, you can allow session cookies to be shared. That means if a user logs in via one site, they could be recognised and treated as logged in by another subsite.
You can enter domains in a subsite's configuration:
This means that two subsites,
Care should also be taken if a subsite can be accessed on multiple URLs or aliases. The configured domain will only be written if the URL that's being used matches one of the domains in the list.
As with session cookies, all of the usual iCM zone and user group security still applies.