Workspace logs

Publishing a log workspace through `web/`

You can expose the product workspace under the static web root by pointing `WORKSPACE_ROOT` to a directory inside or beneath `web/`. For example, your current setup uses `WORKSPACE_ROOT=./var/work`.

Recommended layout

Keep the generated or writable log directory outside the versioned static files, then link only the log subtree into `web/`.

A common pattern is to create a workspace directory such as `./var/work` and expose a selected log folder with a symbolic link under `web/`.

Practical steps

Create the workspace directory, for example `mkdir -p ./var/work`.
Point the application to it with `WORKSPACE_ROOT=./var/work` in `.env`.
Link the required log directory into `web/`, for example `ln -s ../../var/work/log web/log`.
Verify that the link resolves correctly through the static server.

Security requirements

Do not leave the linked log directory publicly readable. The goal is to make it easy to follow gateway activity remotely in a browser, but only with controlled access.

If the logs may contain operational data, protect the directory before you expose it to the web. Two common options are IP-based access control and password protection.

When access control is configured in `web/`, confirm that direct requests to the linked directory are rejected for unauthorized clients and that the protection applies before the link is followed.

Indexing example

Enable directory listing if you want to inspect the log workspace directly in the browser. This is useful for quick remote checks of gateway progress, but it should always be paired with access control.

<VirtualHost *:80>
  ServerName example.local
  DocumentRoot /var/www/github-flows-app/web

  Alias /logs /var/www/github-flows-app/web/log

  <Directory "/var/www/github-flows-app/web/log">
    Options +Indexes
    AllowOverride All
    DirectoryIndex index.html
  </Directory>

  ErrorLog ${APACHE_LOG_DIR}/github-flows-error.log
  CustomLog ${APACHE_LOG_DIR}/github-flows-access.log combined
</VirtualHost>

IP restriction example

This version allows browsing the log directory only from selected networks or hosts. Use it when browser access should be limited to trusted addresses.

Options +Indexes
DirectoryIndex index.html

<IfModule mod_authz_core.c>
  Require ip 127.0.0.1 192.168.1.0/24
</IfModule>

<IfModule !mod_authz_core.c>
  Order deny,allow
  Deny from all
  Allow from 127.0.0.1
  Allow from 192.168.1.0/24
</IfModule>

Password protection example

If remote access must work from arbitrary IPs, protect the log directory with HTTP Basic Auth instead. This keeps the browser workflow simple while still requiring credentials.

Options +Indexes
DirectoryIndex index.html

AuthType Basic
AuthName "Gateway Logs"
AuthUserFile /var/www/.htpasswd
Require valid-user

Operational note

Keep directory indexing enabled, and choose the access control model that matches your deployment. In practice, that means browser users can inspect the log listing, but only from approved IP ranges or after authentication.

If you serve logs from a linked directory, test the exact URL that browsers will open and make sure unauthenticated access returns a denial rather than a directory listing.

Notes

This document describes the static publication pattern only. It does not replace the runtime configuration for the application itself.

Back to home