Forum OpenACS Development: OpenACS 5.9.1: ns_addrbyhost error in util_current_location


util_current_location in /acs-tcl/tcl/security-procs.tcl calls security::validated_host_header, which in turn includes a call to ns_addrbyhost. ns_addrbyhost failes to resolve a domain "test.project-open" that has somehow been returned by util_driver_info. This is also incorrect (hostname -f returns "po51xxx", the URL is ""), but I don't care too much about this one.

However, ns_addrbyhost returns an error if it's not able to resolved this invalid hostname, leading to a complete crash of the application (see below).

We were able to find quickly a workaround (by adding an entry to /etc/hosts for ""). However, I believe security::validated_host_header should be able to handle such a case without causing a hard crash. Maybe just add a catch {...} around ns_addrbyhost?


Here is the error code:

could not lookup
    while executing
"ns_addrbyhost -all $driverHostName"
    (procedure "security::validated_host_header" line 41)
    invoked from within
    (procedure "util_current_location" line 87)
    invoked from within
    (procedure "security::get_register_subsite" line 3)
    invoked from within
    (procedure "::nsf::procs::ad_get_login_url" line 4)
    invoked from within
"ad_get_login_url -return"
    (procedure "::nsf::procs::auth::require_login" line 14)
    invoked from within
    ("uplevel" body line 31)
    invoked from within

The problem above was the configuration on an invalid hostname in the network driver section in the used configuration file (i.e. it was not the hostname provided via URL).

Background: newer versions of OpenACS provide a protection against invalid host header files to protect against HTTP host header attacks. In this process, it checks among many other things, whether the provided content of the host header field is actually one of many possible IP addresses of the hostname provided in the network driver section. In case, this name resolution failed, a runtime exception was generated (what was called "complete crash" above).

One can certainly argue, how to deal with such erroneous configurations, but probably in some testing setups, this can easily happen. The updated code in the OpenACS repository writes now an error message to the error log and skips this single validation step.

As, always, the proper place for such messages is the OpenACS bug tracker.