xowiki - Weblog

Weblog

Showing 1 - 10 of 695 Postings (summary)

Enforcing POST for state-changing requests (require_post)

Created by Gustaf Neumann, last modified by Gustaf Neumann 30 Jan 2026, at 06:54 PM

Motivation

State-changing operations (e.g., create/update/delete actions, membership or role management, administrative tasks) should not be reachable via HTTP GET requests.

GET requests are easy to trigger unintentionally or via social engineering (for example by clicking a link in an email). In modern browsers, session cookies with SameSite=Lax are still sent on cross-site top-level GET navigations, which makes such endpoints vulnerable to CSRF-style attacks if no additional protection is in place.

To reduce this attack surface, OpenACS applications can explicitly require HTTP POST for state-changing requests.

The `::template::require_post` validator

The procedure ::template::require_post enforces that the current request uses the HTTP POST method. If the request is issued using any other method (typically GET), it returns a 405 Method Not Allowed response and aborts request processing.

This validator is intended to be used in the -validate blocks of ad_page_contract and ad_form.

Example A: Using `require_post` in `ad_page_contract`

ad_page_contract { 
    ... 
} -query { 
    email ... 
} -validate { 
    method { require_post } 
    csrf   { csrf::validate } 
} 
# Page implementation follows

In this example:

require_post ensures that the request cannot be triggered via GET.
csrf::validate performs explicit CSRF token validation.

Placing the method check early in the validation phase ensures that invalid requests are rejected before any state-changing logic is executed.

Example B: Using `require_post` in `ad_form`

# If the data is not submitted via a POST request, bail out hard. 
# The request might originate from a forged or unintended request. 

ad_form \
    -name myform \
    -form { 
        {email:text {label "E-Mail"}} ... 
    } -validate {
        {email 
            { [require_post] } 
            "Only POST requests are allowed" 
        } 
    } -on_submit { 
        ... 
    }

This pattern attaches the POST requirement directly to the form validation phase and ensures that the form submission cannot be triggered via a simple GET request.

Caveat: POST is not sufficient by itself

Requiring POST does not replace CSRF protection.

A determined attacker can still trigger cross-site POST requests (for example via auto-submitted forms). Proper CSRF protection therefore must include explicit CSRF token validation.

Requiring POST should be understood as a defense-in-depth measure:

It prevents accidental or link-based triggering of state-changing actions.
It improves the effectiveness of SameSite=Lax cookies.
It reduces the risk of subtle CSRF bugs caused by overlooked GET endpoints.

For full protection, state-changing endpoints should:

Require POST
Validate a CSRF token
(Optionally) perform "Origin" or "Referer" checks for high-risk administrative actions

When to use this pattern

Use require_post for:

administrative pages (e.g., under /admin)
role or permission changes
membership management
any operation that modifies server-side state

Do not use require_post for:

read-only pages
bookmarkable navigation URLs
search, filtering, or pagination endpoints

Security: Cross Site Request Forgery (CSRF)

Created by Gustaf Neumann, last modified by Gustaf Neumann 30 Jan 2026, at 12:55 PM

Starting with OpenACS 5.9.1, OpenACS offers support for protecting against Cross Site Request Forgery (CSRF). In essence, this attack can cause a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The user gets a page presented, which looks harmless, but contains links or images that perform actions with the users credentials without the users consent. Note that the CSP does not protect a user against clicks on a malicious link.

CSRF protection works by ensuring that values for an action (e.g. by from a HTML form) are only accepted from a user that has received the form before. OpenACS generates by its security-procs a secure CSRF token value and provides it to a developer it in a global variable ::__csrf_token. When requests secured with the CSRF token are received, it can be validated on the server side. Note, that this mechanism is similar to "signing" values in OpenACS.

CSRF protection concerns of two parts: add the CSRF token to the form (POST requests) or to the href, and checking the received in the queries expecting input from CSRF protected resources. The first part works technically quite similar as securing CSP via nonces. Add code to the Tcl or ADP page that outputs the global variable (the test for the token is mostly for backwards compatibility)

    <form ...>
        ...
        <if @::__csrf_token@ defined>
           <input type="hidden" name="__csrf_token" value="@::__csrf_token;literal@">
        </if>
        ...
    </form>

Secondly, the page contract on the receiving side has to validate the csrf token. This can be achieved by adding a call to csrf::validate to the validation part of a page contract.

    ad_page_contract {
        @author ...
        @creation-date ...
    } -query {
       ...
    } -validate {
       ...
       csrf { csrf::validate }
    }

In the code base of OpenACS, CSRF protection was added on several places (e.g. public pages, the list template, etc.) such the checks of OpenACS sites on vulnerability scanners improve. Technically, it would be desirable to secure more places against CSRF attacks in the future. However, it depends on the requirements of a site whether e.g. the API browser or search should be CSRF protected. With protection turned on, one cannot share e.g. a link to a search with some other user (or a search engine). A site admin has to decide, how protected/public such links should be.

When using ad_form, the inclusion of the csrf token is done most conveniently via the -csrf_protection_p flag:

    ad_form \
        ... \
        -csrf_protection_p true

References to this Page: en:openacs-todo Categories: Cookbook (OpenACS.org)

OpenACS Compatibility Matrix

Created by Joel Aufrecht, Gustaf Neumann, Michael Aram, Dafydd Crosby, Emmanuelle Raffenne, Carl Robert Blesius, Torben Brosten, Robert Taylor, OpenAI Codex, last modified by Michael Aram 05 Jan 2026, at 10:58 PM

OpenACS requires, at a minimum, an operating system, database, and web server to work. Many additional programs, such as a build environment, Mail Transport Agent, and source control system, are also needed for a fully effective installation.

Table 2.2. Version Compatibility Matrix

OpenACS Version		3.2.5	4.5	4.6.2	5.0	5.1	5.2 (core)	5.3 (core)	5.4 (core)	5.5 (core)	5.6 (core)	5.8 (core)	5.9.0 (core)	5.9.1 (core)	5.10.0 (core)	5.10.1 (core)
AOLserver	3	Yes	No													No
	3.3+ad13	Maybe	Yes					No								No
	3.3oacs1	Maybe	Yes					No								No
	3.4.4	No														No
	3.4.4oacs1	Maybe		Yes	No											No
	3.5.5	Maybe		Yes	No											No
	4.0	Maybe		Yes								No				No
	4.5	No					Yes						No			No
	4.5.2	No					Yes									No
NaviServer	4.99.4 -	No							Maybe		Yes					Yes
NaviServer	5.0 -	No							Maybe		Yes					Yes
Tcl	8.4	Yes										No			No
	8.5.4 -	Maybe							Yes							No
	8.6.7 -	No							Maybe				Yes		Yes
	9.0 -
XOTcl	1.6 -	Yes											No		No
XOTcl	2.0 -	No										Yes			Yes
PostgreSQL	7.4	No			Yes			No							No
	8.0	No				Maybe	Yes					Maybe	No		No
	8.1	No					Yes					Maybe	No		No
	8.2	No					tar: no, CVS: Yes	Yes				Maybe	No		No
	8.3	No								Yes		Maybe	No		No
	8.4	No								Yes			No		No
	9.0	No										Yes			Mostly	No
	9.2	No										Mostly	yes		Mostly	No
	9.4	No											Mostly	yes		No
	11	No												CVS: yes	Yes	No
	12 -	No													Yes
	13 -	No													Yes
	14 -	No													Yes
Oracle	8.1.6	Maybe	Yes					Maybe								Maybe
	8.1.7	Maybe	Yes					Maybe								Maybe
	9i	No			Yes							Maybe				Maybe
	10g	No					Yes					Maybe				Maybe
	11g	No								Maybe						Maybe
	19c															Yes

The value in the cells correspond to the last version of that release, and not necessarily to all minor releases. Empty cells denote an unknown status.

References to this Page: en:docs-install, en:docs-admin-toc Categories: Subsystems Documentation (OpenACS.org)

NaviServer

Created by Gustaf Neumann, last modified by Michael Aram 14 Dec 2025, at 10:25 PM

NaviServer is a fork of AOLserver. While the goal of the AOLserver community is stability (no code changes unless necessary), NaviServer is targeted toward further development and extensions (implementing new features required by state of the art web server environments, see NEWS).

Availability

Releases can be downloaded from sourceforge
The source code of NaviServer and its modules are hosted on GitHub https://github.com/orgs/naviserver-project/repositories.

Using NaviServer with OpenACS

Installation script for many platforms: naviserver-openacs

References to this Page: en:Documentation_Project_Plan, en:references-graph-test Categories: Subsystems Documentation (OpenACS.org)

OpenACS Conferences

Created by Gustaf Neumann, last modified by Gustaf Neumann 20 Jul 2025, at 09:48 AM

Categories: Events (OpenACS.org)

aolserver-market-position-2013-08.png

Created by Gustaf Neumann, last modified by Gustaf Neumann 24 Apr 2025, at 06:15 PM

Name	Content Type	Last Modified	By User	Size (Bytes)
aolserver-market-position-2013-08.png	image/png	2013-08-24 13:36:16+02	Gustaf Neumann	5837

References to this Page: file:aolserver-market-position-2013-08.png Categories: HOME (OpenACS.org)

Install OpenACS with NaviServer from Scratch

Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Mar 2025, at 10:03 AM

This page describes how to install OpenACS with NaviServer on Unix-like systems (e.g. Linux, macOS, Solaris, OmniOS) by compiling all but PostgreSQL from scratch, guided by script that collects the components from various sources, compiles it, etc.

The installation is done in two steps:

install-ns.sh: Install NaviServer and its components for a PostgreSQL installation from scratch by obtaining the relevant sources and compiling it. The script assumes PostgreSQL to be already installed (or obtainable via package managers), and installs all other components by obtaining it from the source repositories and compiling it from scratch (e.g. Tcl, tcllib, tDOM, libthread, nsf/XOTcl 2).
install-oacs.sh: Install OpenACS from CVS/git. This script configures a (pre-installed) PostgreSQL installation for
OpenACS, adds hstore, installs OpenACS core, basic OpenACS packages, xowiki, xowf and optionally dotlrn from CVS/git and generates a config file and startup files (for Ubuntu and Fedora Core). The script assumes a pre-existing NaviServer installation, installed e.g. via install-ns.sh

These install scripts are frequently updated when new components are released or problems are detected (commit log).

If you open the links above, use save-as in the browser to save the files. Alternatively, download the files as .zip file or clone the repository via GitHub.

   cd /usr/local/src
   git clone https://github.com/gustafn/install-ns
   cd install-ns

The scripts work under a typical Linux installation (e.g. Ubuntu, Fedora Core) as well as on Mac OS X or on OmniOS, OpenBSD 6.1, 6.3, 6.6, 6.8, 6.9, FreeBSD 12.2, 13.0, Ubuntu 12.04, 13.04, 14.04, 16.04, 18.04, 20.04, Raspbian GNU/Linux 9.4 (stretch), Fedora Core 18, 20, 32, 35, CentOS 7, Roxy Linux 8.4, ArchLinux.. The scripts are tested (over the years) with PostgreSQL 9.1 to 14.5.

On a fresh Ubuntu installation, you should be able to download the two scripts from this page and install OpenACS with NaviServer in the following steps:

   sudo bash

   bash install-ns.sh
   bash install-ns.sh build

   bash install-oacs.sh
   bash install-oacs.sh build

When running "install-ns.sh", you will see an output like the following (shortened here).

SETTINGS   build_dir              (Build directory)                 /usr/local/src
           ns_install_dir         (Installation directory)          /usr/local/ns
           version_ns             (Version of NaviServer)           4.99.24
           git_branch_ns          (Branch for git checkout of ns)   main
           version_modules        (Version of NaviServer Modules)   4.99.24
           version_tcllib         (Version of Tcllib)               1.20
           version_thread         (Version Tcl thread library)      
           version_xotcl          (Version of NSF/NX/XOTcl)         2.4.0
           version_tcl            (Version of Tcl)                  8.6.12
           version_tdom           (Version of tDOM)                 0.9.1
           ns_user                (NaviServer user)                 nsadmin
           ns_group               (NaviServer group)                nsadmin
                                  (Make command)                    make
                                  (Type command)                    type -a
           ns_modules             (NaviServer Modules)              nsdbpg
           with_mongo             (Add MongoDB client and server)   0
           with_postgres          (Install PostgreSQL DB server)    1
           with_postgres_driver   (Add PostgreSQL driver support)   1
           with_system_malloc     (Tcl compiled with system malloc) 0
           with_ns_doc            (NaviServer documentation)        1

The values in the first column can be used to tailor the system for your needs by setting same-named shell variables. One can use e.g.

   version_tdom=0.9.3 bash install-ns.sh

to configure the compilation to use tDOM in version 0.9.3 instead of 0.9.1. As a more detailed example, if you want to use the newest (most likely unreleased) version of NaviServer, and you want to use a different build directory and get also some extra modules compiled from their git versions, use e.g. the following command:

   version_ns=GIT \
      build_dir=/usr/local/src-test \
      ns_modules="nsdbpg nsdbi nsdbipg nsudp nssmtpd nsloopctl" \
      bash install-ns.sh

For standard setups, the default settings should be OK.

After running both scripts in the default configuration, you will see e.g.

   Congratulations, you have installed OpenACS with NaviServer on your machine.
   You might start the server manually with
       sudo /usr/local/ns/bin/nsd -t /usr/local/ns/config-oacs-5-10-0.tcl -u nsadmin -g nsadmin

One can start the server manually with the mentioned command.

Using `systemd`

On Fedora/CentOS or on Ubuntu installations starting with 15.04, systemd is used. The generated startup file for RedHat/Fedora is in /lib/systemd/system/oacs-5-10-0.service. The startup commands for systemd are

    sudo systemctl status oacs-5-10-0
    sudo systemctl start oacs-5-10-0
    sudo systemctl stop oacs-5-10-0

Remember, when a new systemd service is installed, systemd requires the following command to re-scan its service files:

    sudo systemctl daemon-reload

To start OpenACS automatically on every new start of the machine, issue the following command:

    sudo systemctl enable oacs-5-10-0

Using `upstart`

Alternatively, some older Ubuntu versions (up to 15.04) use upstart. For upstart, the the generated startup file is in /etc/init/oacs-5-9-1.conf. The service can be started/managed with the following commands

    sudo initctl status oacs-5-10-0
    sudo initctl start oacs-5-10-0
    sudo initctl stop oacs-5-10-0

Configuration

When the service is running, one can use OpenACS by browsing to http://localhost:8000/ (when the browser and server is running on the same host). The relevant files are stored under the following locations:

Configuration file	`/usr/local/ns/config-oacs-5-10-0.tcl`
`access.log`	`/var/www/oacs-5-10-0/log/`
`error.log`	`/var/www/oacs-5-10-0/log/`
Source tree	`/var/www/openacs-5-10-0/packages/`

References to this Page: en:docs-install, en:openacs-system-install, en:openacs-system-install-redhat, en:aolserver-admin, en:os-nix-install, en:openacs-system-install-osx, en:openacs-system-install-debian, en:Debian_Ubuntu_installation, en:openacs_monitoring, en:Documentation_Project_Plan, en:packaging, en:libthread, en:upgrade-oacs-5-9, en:cookie-consent, en:boomerang, en:naviserver, en:references-graph-test, en:cache-size-tuning, en:upgrade-oacs-5-10, en:oacs-5-10-on-oracle-19c Categories: Subsystems Documentation (OpenACS.org)

NaviServer and OpenACS with Docker

Created by Gustaf Neumann, last modified by Gustaf Neumann 02 Oct 2024, at 02:33 PM

The Docker images as presented at the OpenACS/Tcl conference 2024 (slides, recording for NaviServer and OpenACS are available at:

These images are available for Intel 64 bit and ARM 64 (e.g. Apple Silicon). See also the forums posts concerning these images:

Categories: Cookbook (OpenACS.org)

Installing OpenACS on Windows

Created by Maurizio Martignano, last modified by Maurizio Martignano 04 Sep 2024, at 11:41 AM

Windows-OpenACS (vers. 5.16.0 - September 2024) is a Windows 64 port of OpenACS 5.10.1 and the latest snapshot of NaviServer and is available at Spazio IT.

This port installs and runs on the following systems: