@summersec/dsh-web-auth

Advanced configuration

The bundle:

1. Sets the stock webserver row to disabled: true.
2. Inserts webserver-auth with name @summersec/dsh-web-auth.

DSH patches replace config as a whole. To override advanced fields, restate the full webserver-auth block in the profile patch (e.g. profile cordis.patch.yml):

- id: webserver-auth
  name: '@summersec/dsh-web-auth'
  inject: [webStartup]
  config:
    host: !!js ctx.webStartup.host ?? '127.0.0.1'
    port: !!js ctx.webStartup.port ?? 3080
    authMode: always
    username: admin
    passwordHash: !!js process.env.WEB_AUTH_PASSWORD_HASH
    sessionTtlMinutes: 720
    maxAttempts: 5
    attemptWindowSeconds: 300
    secureCookie: auto
    trustProxy: false

Config reference

Field	Type / values	Default	Notes
host	127.0.0.1 | 0.0.0.0	127.0.0.1	Listen address (from web startup)
port	0–65535	3080	Listen port; 0 for ephemeral
authMode	always | non-loopback	always	See Authentication modes
username	string	admin	Single shared account
password	string	—	Plaintext; avoid in production
passwordHash	scrypt$...	—	Required format from the CLI
sessionTtlMinutes	1–43200	720 (12h)	Sliding window on each authenticated request
maxAttempts	1–1000	5	Failed logins per IP per window
attemptWindowSeconds	1–86400	300	Attempt window length
secureCookie	auto | always | never	auto	When to set the Secure flag
trustProxy	boolean	false	Trust X-Forwarded-* only behind a locked-down proxy

secureCookie and trustProxy

Scenario	Suggested settings
Local HTTP on loopback	secureCookie: auto, trustProxy: false
Direct TLS on the Node process	secureCookie: auto (sets Secure when the socket is encrypted)
HTTPS terminated at nginx / Caddy / Cloudflare	secureCookie: auto or always, trustProxy: true, and only the proxy may reach DSH’s port

If trustProxy is true while the port is reachable by untrusted clients, attackers can spoof X-Forwarded-For / X-Forwarded-Proto and weaken IP limits or cookie security. Lock network access first.

---