History: Multi-domain

Source of version: 7 (current)

! Multi-domain
Allows to map domain names to ((perspectives)) and simulate multiple domains hosted on the same instance. This is useful to have distinct micro-sites within a single Tiki instance.

This will probably not work for Tiki instances in sub-directories

New in ((Tiki4)) and improved in ((Tiki5)).


! Single Sign On
!! Sub-domains
For sub domains hosted on the same machine, all you should have to do for multi domain is to set the cookie domain to include sub domains (.example.com, with the initial dot).

!! Different domain names
For different domain names, the issue is not about tiki. The web browsers simply won't send the cookies across domain. It's meant as a security measure.

Authentication is required for all domains. There is no way around it. You can google as much as you want, at best, you will find some unreliable hack that will work for a fraction of your users.

Single sign-on can reduce the issue by using a trusted third party and some encryption. That is what ((OpenID)) and ((CAS)) do. The user still needs to request authentication, but under the best scenario, that becomes a series of transparent redirects.

The purpose of multi-domain is to brand a single site differently for different sets of users. Asking the same users to go through a large set of different domains is just asking for trouble. It's confusing and I believe enough to break their trust in the site. I wouldn't appreciate if my bank changed domain name from one page to the next.



Related: 
* ((Domain redirects))
* ((Domain prefix handling))

-=alias=-
* (alias(MultiDomain))
* (alias(MultiSite))