Merge pull request #78 from theta42/release/v1.3.2

Release v1.3.2: bump proxy to v1.2.2 (fixes load-balancing crash)

CHANGELOG.md

@@ -10,6 +10,56 @@ for what changed inside the apps it composes.
 
 ## [Unreleased]
 
+## [1.3.2] - 2026-07-21
+
+### Bumped
+- proxy -> [v1.2.2](https://github.com/theta42/proxy/releases/tag/v1.2.2)
+
+proxy:
+
+### Fixed
+- Multi-target load balancing (added in 1.2.0) crashed every request to a load-balanced host: `ops/nginx_conf/targetinfo.lua` required a nonexistent `resty.balancer.round_robin` module. The `lua-resty-balancer` rock actually installed provides `resty.roundrobin` instead, with a different constructor API. Fixed `targetinfo.lua` to use the real module — verified end-to-end that requests now round-robin across targets with no Lua errors.
+
+## [1.3.1] - 2026-07-21
+
+### Bumped
+- proxy -> [v1.2.1](https://github.com/theta42/proxy/releases/tag/v1.2.1)
+- sso-manager-node -> [v1.1.18](https://github.com/theta42/sso-manager-node/releases/tag/v1.1.18)
+
+proxy:
+
+### Fixed
+- The bootstrap anti-lockout admin account was always created as `proxyadmin2` regardless of `conf.auth.adminUsers`, while `migrations/permission_bootstrap.js` grants the global-admin permission to `conf.auth.adminUsers[0]`. If an operator customized `adminUsers` away from the default, the bootstrapped account and the permissioned account were two different (non-matching) usernames, so the anti-lockout account ended up with no admin access. `models/user_redis.js` now derives the bootstrap username from `conf.auth.adminUsers[0]` (falling back to `proxyadmin2`), matching `permission_bootstrap.js`.
+- Corrected a `secrets.js.example` comment that claimed the bootstrap admin's password "defaults to the username itself" — it actually generates a random password printed to the container log on first boot.
+
+### Changed
+- Refreshed all README screenshots (hosts, per-host SSO auth, per-host basic auth) against the current UI, and added a new load-balancing screenshot for the multi-target feature.
+
+sso-manager-node:
+
+### Added
+- N-Way Multi-Master LDAP replication: `LDAP_SERVER_ID` + `LDAP_REPLICATION_HOSTS` configure `syncrepl` peers in the bundled OpenLDAP, and a new `/sites` page (nav: **Sites**) shows each configured peer's LDAP URL and live reachability.
+- A `location` property on users, editable from the profile and user-edit forms.
+
+### Fixed
+- `/sites` (added above) 500'd on every load: `views/sites.ejs` included nonexistent partials `header`/`footer` instead of this app's actual `top`/`bottom`. Fixed to match every other view.
+
+### Changed
+- Refreshed all README screenshots (dashboard, users, groups, OAuth apps) against the current UI, and added a new Sites & Replication screenshot.
+
+### theta-env own changes
+- Refreshed `docs/images/sso-dashboard.png` and `docs/images/proxy-hosts.png` to match the submodules' updated screenshots.
+
+## [1.1.20] - 2026-07-20
+
+### Bumped
+- proxy -> [v1.1.17](https://github.com/theta42/proxy/releases/tag/v1.1.17)
+
+proxy:
+
+### Fixed
+- An existing single-label subdomain host (e.g. `sso.nl.wgnode.com`) could not be attached to a wildcard cert added later (e.g. `*.nl.wgnode.com`): `Host.lookUpWildcardParent()` only checked the wildcard-as-child position (the wildcard's own base domain) and missed the far more common wildcard-as-sibling case, so the edit form's "Parent Wildcard" option stayed permanently greyed out. It now checks both positions, and a regression test covers the sibling case.
+
 ## [1.1.19] - 2026-07-18
 
 ### Bumped
@@ -282,7 +332,7 @@ First tagged release. Establishes the `vX.Y.Z` tag convention going forward.
 - proxy -> [v1.1.0](https://github.com/theta42/proxy/releases/tag/v1.1.0)
 - sso-manager-node -> [v1.1.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.1.0)
 
-[Unreleased]: https://github.com/theta42/theta-env/compare/v1.1.18...HEAD
+[Unreleased]: https://github.com/theta42/theta-env/compare/v1.1.20...HEAD
 [1.1.17]: https://github.com/theta42/theta-env/compare/v1.1.16...v1.1.17
 [1.1.16]: https://github.com/theta42/theta-env/compare/v1.1.15...v1.1.16
 [1.1.15]: https://github.com/theta42/theta-env/compare/v1.1.14...v1.1.15

README.md

@@ -60,6 +60,10 @@ It is **both** an OIDC client of the SSO (for login) **and** a direct LDAP
 client (for user lookups). Legacy apps can still bind to LDAPS on the SSO
 directly.
 
+- **Self-service API tokens** in both apps' UIs, for scripting/CI without a browser session.
+- **Multi-Site Support (Geo-Location Scaling)** — built-in support for N-Way Multi-Master LDAP replication across physical locations.
+- **Multi-target load balancing** — built-in proxy support for round-robin load balancing across multiple application servers.
+
 ---
 
 ## Before you begin

docker-compose.yml

@@ -56,6 +56,8 @@ services:
       # reads that are not part of its conf tree.
       - NODE_ENV=production
       - NODE_PORT=3001
+      - LDAP_SERVER_ID=${LDAP_SERVER_ID:-}
+      - LDAP_REPLICATION_HOSTS=${LDAP_REPLICATION_HOSTS:-}
     volumes:
       # Operator-edited SSO secrets (sso-secrets.js). Read-WRITE so the bootstrap
       # can write the generated OAuth client creds into proxy-secrets.js. The

docs/index.md

@@ -44,6 +44,8 @@ snapshots state before every rebuild.
 - **LDAPS** for legacy apps that bind directly.
 - **Self-service API tokens** in both apps' UIs, for scripting/CI without a
   browser session.
+- **Multi-Site Support (Geo-Location Scaling)** — built-in support for N-Way Multi-Master LDAP replication across physical locations.
+- **Multi-target load balancing** — built-in proxy support for round-robin load balancing across multiple application servers.
 
 ## Get it
 

pr_url.txt

@@ -0,0 +1 @@
+https://github.com/theta42/theta-env/pull/75

setup.env.example

@@ -58,4 +58,16 @@ CFG_DOMAIN=example.com
 # password is the exception — see ./config/proxy-secrets.js's auth.localAdminPass
 # comment for how to actually change it after the account exists). Do NOT set
 # CFG_LDAP_ADMIN_PASS / CFG_JWT_SECRET / CFG_ADMIN_PASS / CFG_SVC_PASS /
-# CFG_PROXY_ADMIN_PASS here.
+# CFG_PROXY_ADMIN_PASS here.
+
+# ── Geo-Location Scaling (N-Way Multi-Master LDAP) ───────────────────────────
+# If deploying this stack across multiple physical sites to provide local HA
+# for directory services, you can enable N-Way Multi-Master OpenLDAP replication.
+# This requires assigning a unique ID to each site and listing the LDAPS URLs
+# of all OTHER sites in the cluster.
+#
+# Each site MUST have a unique LDAP_SERVER_ID (e.g. 1, 2, 3).
+# LDAP_REPLICATION_HOSTS is a space-separated list of the other sites' LDAP URLs.
+# Example for Site 1:
+#LDAP_SERVER_ID=1
+#LDAP_REPLICATION_HOSTS="ldaps://sso.site2.com:636 ldaps://sso.site3.com:636"