Forum OpenACS Development: Re: Docker NaviServer and OpenACS suite on GitHub

Collapse
Posted by Claudio Pasolini on
Starting from the oacs-db-inclusive image, I set up two containers (oacs-a and oacs-b) that communicate with a separate Postgres container. Portainer shows all instances as healthy, and the host ports are properly published.

My goal is to run multiple instances listening only on HTTP, letting Nginx handle HTTPS. To achieve this, I modified the YAML file by setting httpsport="" and removed all HTTPS-related sections from openacs-config.tcl.

The instances start normally, and I successfully completed the installation from the Welcome page. However, after restarting the browser (both Chrome and Firefox), it always redirects to https://127.0.0.1:8080. In contrast, accessing http://localhost:8085 with curl or lynx works fine.

In the logs, I see:
Notice: security::locations add connected location http://127.0.0.1:8085

immediately followed by:
Notice: security::locations add connected secure location https://127.0.0.1:8080

I'm not sure if this is a browser issue or an OpenACS problem.

Claudio

Collapse
Posted by Gustaf Neumann on

Hi Claudio,

a few clarifications that may help narrow this down:

  • To disable HTTPS handling inside the OpenACS container, it is not necessary (and not recommended) to remove HTTPS-related config sections. It is sufficient to unset/comment out oacs_httpsport. Removing HTTPS entirely means OpenACS loses its secure context, which can have side effects.

  • When running OpenACS behind a reverse proxy (e.g. Nginx handling HTTPS), OpenACS must be explicitly configured for this. In the current container setup this is done via ns/parameters/reverseproxymode which can be set in docker-compose.yml using oacs_reverseproxymode. Without this, OpenACS will have 'wrong' peer addresses, i.e. the proxy server itself.

  • It is also important to clarify whether oacs-a and oacs-b are meant to be independent instances or the same instance accessed twice. In the latter case, a proper cluster configuration is required; otherwise you will see inconsistencies (including location handling).

  • In a proxy-based setup, OpenACS ports normally should not be exposed at all—only the proxy ports should be published.

Regarding the redirect itself: browsers tend to cache scheme decisions (and sometimes HSTS-like behavior even on localhost/127.0.0.1), while tools like curl or lynx do not. Combined with OpenACS registering a “secure location” early at startup, this can easily explain why only browsers redirect to HTTPS.

all the best -g

Collapse
Posted by Claudio Pasolini on
Many thanks for the clarification, Gustaf!

Setting oacs_httpsport and oacs_reverseproxymode resolved the issue. Both instances are now working normally and are reachable via Nginx.

Claudio