View · Index


Filtered by popular tag host-node-map, 1 of 1 Postings (all, summary)

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).

previous April 2024
Sun Mon Tue Wed Thu Fri Sat
31 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 1 2 3 4

Popular tags

17 , 5.10 , 5.10.0 , 5.9.0 , 5.9.1 , ad_form , ADP , ajax , aolserver , asynchronous , bgdelivery , bootstrap , bugtracker , CentOS , COMET , compatibility , CSP , CSRF , cvs , debian , docker , docker-compose , emacs , engineering-standards , exec , fedora , FreeBSD , guidelines , host-node-map , hstore
No registered users in community xowiki
in last 30 minutes