Forum OpenACS Development: Allow Host Node Mapped Host Names for Cookies

I am looking into allowing host node mapped host names that are not a subdomain of the main site to be allowed to generate cookies, even if CookieDomain parameter is set.

I think something like this procedure to be used when setting cookiedomain could be useful.

ad_proc sec_get_cookiedomain {} {
    Get the CookieDomain
    Support host-node-mapped domains that are not a subdomain of the
    main subsite
} {
    set domain [parameter::get -parameter CookieDomain -package_id [ad_acs_kernel_id]]
    set location [util_current_location]
    if {![regexp [string map {. \\.} $domain] $location]} {
        set host_node_map_hosts_list [db_list -cache_key security-locations-host-names get_node_host_names "select host from host_node_map"]
        foreach host $host_node_map_hosts_list {
            ns_log notice "Checking host '${host}'"
            if {[regexp [string map {. \\.} $host] $location]} {
                set domain $host
            }
        }
    }
    return $domain
}
Collapse
Posted by Gustaf Neumann on
Using domain cookies is in general quite dangerous, especially, where there are multiple OpenACS installations under the same domain (see below). a further complication can happen with host-node map entries, which are no subsites. ... so my recommendation is in general to use domain cookies carefully. What problem are you addressing?

When trying to set up independent looking host-node-mapped subsites, it might be useful to different cookie names, e.g. using a cookie suffix derived from host-node-map entry.

-g

Sample problem case: Imaging a server foo.some-domain.com and another server bar.some-domain.com. and "foo" sets the cookie domain (and provides domain cookies), a request to "bar" (which has no cookie domain set) will receive the domain cookie from "foo" and the non-domain cookies, leading to actually two session cookies, login-cookies etc.. this can lead to strange behavior, hard to debug.

Collapse
Posted by Dave Bauer on
Gustaf,

Thanks, I think I need to learn more about how this works and get some more information about how this should be set for a specific installation.

Can you clarify your example?

Are foo. and bar. served by the same Naviserver instance or are they separate sites?

Collapse
Posted by Gustaf Neumann on
The same Problem will arise, when foo and bar are served by the same nsd, by different OpenACS instances on the same machine, or different openacs instances on different machines.

What are you trying to achieve?

Collapse
Posted by Dave Bauer on
Thanks Gustaf, I am trying to see if I can clarify the requirements, to make sure we are doing the right thing. I appreciate your explanations.

If cookie domains are a problem, perhaps we need to remove or identify the issue with that setting?

Collapse
Posted by Gustaf Neumann on
Whatever "problem" means: I was pointing out to the fact, that mixing domain cookies and non-domain cookies is not a good idea, since current browsers will sent these cookies twice (once as domain cookies, once as "normal" (site) cookies). Image a user logging first (1) into to foo.company.org and later (2) into bar.company.org, where the foo uses site cookies, and bar sets it cookies as domain cookies of "company.org". When the user visits then as visit (3) again foo.company.org the server will see duplicate "ad_login" "ad_session_id", etc. cookies, causing all kind of confusions.

my message was just: think twice, when using domain cookies.
To your original question: yes, there should be a way to set optionally a cookie domain for host-node-mapped sites for orthogonality, but that should be possible from the web ui.

The second point was: the cookie-name confusion can be avoided, when we set e.g. a "cookie realm", like "development", "external", ... which could be appended to the cookie name (e.g. "ad_login-external", then there can't be any kind of confusion like indicated above.