• last updated 8 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
In the end we do phase out the util_expand_entities* procs for being too lame

Good riddance

a protocol relative URL is not complete, but it can be understood as external

Make util_complete_url_p recognize protocl-relative URLs

Extend the test cases for util_complete_url_p with a case of protocol-relative URL

Reimplement util_expand_entities_ie_style

This proc turned out to be long broken. We could consider phasing it out, but as it is a public interface used in a few places we prefer to keep it around and try to fix it.

The intended behavior has been reconstructed from the documentation. The new approach uses a single regexp to extract entities, which does not risk to loop indefinitely as before.

Test util_expand_entities and util_expand_entities_ie_style

This test will show that since the long broken parenthesys in util_expand_entities_ie_style were fixed in a recent commit, this proc will just not work.

After further consideration, ns_absoluteurl is actually sufficient to preform location header completion on its own and does not need a wrapper utility

  1. … 1 more file in changeset.
Streamline terminology with other occurrences in OpenACS and NaviServer/AOLserver

- the term "location" is usually used in OpenACS/NaviServer/AOLserver for the

part of a URL before the path (i.e. SCHEME+HOST+PORT)

- the new function util::absolute_url is a value-added version of NaviServer's "ns_absoluteurl".

This is now documented with its differences, and aligned with its terminology

fixed broken indentation and broken nesting

    • -1149
    • +1148
    ./tcl/text-html-procs.tcl
fixed indentation of braces

fix incorrect nesting in switch statements

added "variable" declaration to avoid potential namespace confusion

Introduce util::complete_location

This utility is meant to require the value of the Location header in an HTTP response to be completed vith the host coming from a reference complete URL, which is normally that of the redirected request.

It is intended for use in the context of HTTP client APIs, where we want to handle server responses affected by https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2

  1. … 1 more file in changeset.
use original provided host-header-field in log statement

escape variable in log statement

Fix another variable name after refactoring

Fix variable name after refactoring

fixed typo

Updated location handling

- make use of "ns_server hosts" when available

- refactored and simplified code

- keep validated locations in an nsv array

- added support for extra white-listed hosts

in case, every other configuration fails

(should not be necessary)

ns_section ns/server/$server/acs {

ns_param whitelistedHosts {...}

}

- updated inline documentation

The new code is supposed to handle in combination of a recent NaviServer

all complex host header validation scenarios, include running behind a proxy,

in a container or cluster.

Updated icanuse registry

- added "ns_ip", "ns_subnetmatch", and "ns_server hosts"

- sorted commands alphabetically

whitespace changes

modernize code

moved long time deprecated function "ad_approval_system_inuse_p" to deprecated-procs

Improved comments and make code more robust in regards of legacy setups

    • -12
    • +20
    ./tcl/request-processor-procs.tcl
Added support for relative redirects

RFC 2616 requires an absolute URI in the "Location" header field. So

if someone calls "ns_returnredirect /", NaviServer transforms it on

the fly into an absolute URL by prefixing it with the location

(e.g. https://openacs.org/). NaviServer (and OpenACS) has some complex

code to compute the location value, especially when virtual servers

are involved (or for "host-node mapped" subsites in OpenACS). The

situation is further complicated when running behind a reverse proxy

and/or in a containerized environment. In such cases, the location is

computed from the "host" request header field, which must be

validated, otherwise an attacker could hijack a session and redirect

it to a spoofed site.

The situation changed 10 years ago (June 2014) with the introduction

of RFC 7231, which allows relative redirects (see

https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2). Using relative

redirects greatly simplifies configuration and closes the attack

vector using the host header field. RFC 7231 has been superseded by

RFC 9110 (June 2022), which also supports relative redirects via the

"location" response header field (see

https://www.rfc-editor.org/rfc/rfc9110#field.location).

Since OpenACS prefixed always the URL with a location, when it

encounters are relative URL in a "ad_returnredirect", this change

makes use of the new feature of NaviServer 5.

Make sure to use a current version of NaviServer, where the support

was added recently.

improved robustness during bootstrap

improved speling

improved spelling

  1. … 1 more file in changeset.
Extended "ad_conn behind_secure_proxy_p"

This test will be now true, when either the recieved request

contains one of those request header fields.

- "X-SSL-Request: 1"

- "X-Forwarded-Proto: https"

Before, only the first variant was accepted.

The AWS load balancer uses the second variant.

fix typo