Host Node Map
Created by Gustaf Neumann, last modified by Gustaf Neumann 30 May 2017, at 02:28 PM
The host-node-map (see /acs-admin on your OpenACS installation) is a means to map virtual host names to sub-sites or to applications. Depending on the type of mapping, different options are available.
If one maps for instance a host name to an application package instance (i.e. the root url of the application is seen under / under host-node-mapped name, then site-wide services (such as search, register, site-wide administration) might or might not be available. If one want's to offer services to non-registered users, this might be perfectly fine.
When the mapping is against a sub-site, all sub-site services will be available (e.g. /register). This type of mapping can be useful for typical virtual host setups, where different sub-sites might be equipped with different themes.
In order to setup a host-node-mapping, one has to provide multiple names (typically DNS entries) for the same machine and to define then under /acs-admin the association between host names and site nodes.
The setup is influenced by a few parameters such as UseHostnameDomainforReg and CookieDomain. When UserHostnameDomainforReg is set true (default: false), all registrations initiated at the sub-site will be redirected to the main site. In these cases, the login cookie will be issued by /register for the main site, unless the CookieDomain is set appropriately. It is currently not supported to register users on completely different domains (not sharing a common root owned y the site master).
The situation with a host-node mapping to application packages is very similar to the last paragraph. Also in these cases, the /register url (generated via ad_get_login_url) will be mapped to the nearest sub-site, which might be the main site.
When using host-node-maps, don't use mixed HTTP/HTTPS setups based on RestrictLoginToSSLP. Also the usage of the (recommended) Strict-Transport-Security setting (setup via the NaviServer config file, see e.g. openacs-config.tcl) might interfere with RestrictLoginToSSLP. So the usefulness of the parameter is nowadays somewhat limited. The general trend is to use HTTPS for the full site (and all sub-sites as well).
