- Removed a dead IE<9-only html5shim script tag pointing at a domain
that no longer resolves.
- New GET /docs (index) and /docs/:slug routes render this project's
own README, DEPLOYMENT, API.md, docs/*.md, and directory_spec.md
server-side via marked -- so the documentation is readable from the
running app with no route to GitHub Pages, where it otherwise only
lives. Public, no auth, rate-limited (middleware/rate_limit.js) like
the other public routes.
- .dockerignore/Dockerfile.openldap updated to copy DEPLOYMENT.md,
API.md, directory_spec.md, and docs/ into the image, mirroring the
existing tos.md -> /tos.md convention.
tos.md was baked into the repo and read once at startup, so changing
the terms required a code change and deploy. It's now a Redis-backed
singleton (models/tos.js), editable from a new "Terms of Service" card
on the admin Dashboard, with the bundled tos.md used only as a
one-time seed for new deployments.
- routes/tos.js: GET (any authenticated user) / PUT (app_sso_admin
only) via /api/tos. Saving can optionally reset every user's
tos_accepted flag so they're asked to re-accept -- off by default,
since a wording fix shouldn't re-prompt everyone.
- routes/index.js: /tos and /onboarding now render the live content
instead of a module-level constant computed once at process start.
ops/backup.sh snapshots LDAP (slapcat), Redis (BGSAVE, dynamic RDB path
lookup), and ./config for standalone deployments, with retention. A
background service polls GitHub releases every 24h and surfaces an
admin-only banner in the UI when a newer version is published.
The Integrations page's Service Accounts (bind-only, organizationalRole)
don't cover the other real use case: an account something actually runs
as on a Linux host -- a media manager, a torrent client, Emby -- with a
real uidNumber/gidNumber that owns files, and a group other accounts
join for write access (e.g. a `stuff_manager` group granting write
rights to a media library). That needs a real posixAccount, which the
bind-only model can't be.
- New well-known group `app_sso_service_account`, seeded the same way as
app_sso_admin/app_sso_invite/app_sso_oauth_admin (docker-entrypoint.sh,
ops/ldap-setup.sh). Not a permission gate -- a marker.
- "Add new user" form gets a "This is a service account" checkbox: swaps
the person-shaped fields (first/last name, birthday, ToS agreement)
for a single account-name field, since none of those make sense for a
non-person account. On create, the route adds the user to
app_sso_service_account.
- User.listDetail() annotates each user with isServiceAccount (checked
against the marker group's member list once per call, not the memberof
overlay's reverse attribute -- not reliably returned by every LDAP
server this app might point at, confirmed against a real external
directory during testing). Users page shows a "service" badge.
- Notification broadcasts (filter_type=all/all_active) exclude service
accounts by default -- nobody reads mail as `stuff_manager`.
- Fixed a real, previously-unrelated bug this surfaced: addPosixAccount
unconditionally set `mail: data.mail` in the LDAP entry even when
undefined, and ldapts/slapd reject an attribute given an explicit
undefined value ("no values for attribute type") rather than treating
it as absent. This meant creating ANY user without an email already
failed outright -- not something a service account (which commonly has
no real mailbox) could route around. Made mail conditional, matching
how mobile/sshPublicKey/dob already work.
- docs/ldap.md now explains both kinds of service account side by side
and when to use which.
Verified end-to-end against a real external LDAP server (not a local
sandbox): created a service account with no email, confirmed it's
correctly flagged and excluded from broadcast recipient resolution,
confirmed a normal user is unaffected, confirmed the code degrades
gracefully if the marker group doesn't exist yet (pre-upgrade
deployments).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- OAuth Apps and LDAP Info are both "how do other apps/hosts plug into
this SSO" concerns -- merged into a single /integrations page with
tabs, replacing the two separate nav items with one. /oauth-clients
and /ldap-info 301-redirect there for compat.
- Add a Service Accounts section under the LDAP tab: bind-only LDAP
identities (organizationalRole + simpleSecurityObject, no
posixAccount) for apps/hosts, as opposed to real people. Create,
rotate password, and delete, all from the UI -- previously the only
such account (theta-env's bootstrap-created cn=ldapclient) was
invisible to the Users page entirely (filtered out by
conf.ldap.userFilter) and had no GUI way to see or rotate it; the new
ServiceAccount model uses the exact same objectClasses bootstrap.js
already creates cn=ldapclient with, so it recognizes and manages that
account too, not just ones created through this UI.
- The ldap-client bash snippet now points at "create one under Service
Accounts above" instead of a bare textual example.
Verified against a real LDAP server (not just the dev sandbox's usual
unreachable one): created a service account, confirmed it binds
successfully with the generated password, rotated its password, and
deleted it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New admin-only page (nav: "LDAP Info") that answers "what do I put in my
app's LDAP settings" without reading a doc: LDAPS URL, base DN, user/group
search bases, user filter, username attribute, and an example bind DN, all
derived from the running conf.ldap + request host rather than hardcoded --
so it's always correct for the actual deployment, copy-button on every
field.
Also generates a copy-pasteable bash snippet that clones
theta42/ldap-client and writes its ldap.vars file with the real host/base
DN/sso_url already filled in (bind password and SSO API token left as
placeholders with inline instructions, since those need to be created,
not derived).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Compose form's "Send to" radio group had "All active users" checked
by default with no confirmation before Send -- anyone opening the
Dashboard to see how the feature works, typing a test subject/message,
and clicking Send would broadcast to every active user. Remove the
default (a target must now be explicitly chosen) and require a confirm
step before actually sending to "all" or "all_active".
Also add a hard safety net in models/email.js: Mail.send is a no-op
under NODE_ENV=test, so the automated test suite (which exercises the
real notification/password-reset/invite/OTP-by-email routes with
NODE_ENV=test) can never deliver real mail regardless of what recipient
list a test resolves.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
It linked to fixed personal infrastructure (718it.biz, vm42.us,
git.theta42.com) with an admin's name in one label — not appropriate for
what should be a generic, publicly-releasable template. Flagged in
theta42/sso-manager-node#45, tracked as #46; resolves that issue.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
theta42/proxy fronts an arbitrary number of hosts behind SSO, each with its
own callback URL (https://<host>/__proxy_auth/callback) — proxy's own code
comment already assumed "a wildcard redirect URI covers all", but no
wildcard matching existed here, so every proxied host's callback had to be
registered on the shared OAuth client individually or /oauth/authorize
would reject it with InvalidRedirectURI.
Add `*` (one hostname label) / `**` (any number of labels) wildcard support
to redirect_uri matching, e.g. `https://**.example.com/__proxy_auth/callback`
now covers every host proxy fronts under example.com. Exact matches still
work exactly as before.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Replace the separate Profile/API Tokens nav items with a single link
showing the logged-in user's name, pointing at their own profile.
- Merge admin.ejs + notifications.ejs into a new dashboard.ejs page.
/admin and /notifications now 301-redirect to /dashboard.
- Fold the API Tokens page into profile.ejs as a self-service-only
section, gated on isOwnProfile so it never appears when an admin
views another user's profile via /users/:uid. /api-tokens 301s to /.
- Fix: the section must not carry class="row" — app-base.js runs a
page-wide $('div.row').fadeIn() on every page load that would reveal
it regardless of the isOwnProfile check, since it fires before this
page's own gating logic.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Auditing mobile/responsive views turned up two classes of bug:
1. Missing .table-responsive wrapper (token.ejs and profile.ejs's other
table already had it): admin.ejs (2 tables), invites.ejs (6 columns),
notifications.ejs (5 columns), users.ejs (7 columns — the worst case).
Without it these overflow the page horizontally on narrow viewports
instead of scrolling within the table.
2. groups.ejs's search/sort/count toolbar was a plain `d-flex` (no
flex-wrap) containing a search input, a <select> with a hard
min-width:175px, and a nowrap count span — on a narrow viewport
there's nowhere for that content to go but off-screen. Added
flex-wrap and gave the search input a flex-basis so it wraps onto
its own line first when space is tight.
Verified: EJS compiles for all five templates, npm test 192/192 pass,
and fetched each route from a running instance to confirm the fixes
are present in the served HTML.
- api_tokens.ejs: created_on/last_used_on come back from Redis as strings
(model-redis only coerces fields with an explicit `type`), so `new Date(ms)`
yielded "Invalid date". Use `moment(ms, "x")` (the hosts.ejs/dns.ejs
precedent) which parses a numeric string-or-number as a Unix-ms timestamp.
- api_tokens.ejs: `isExpired` is a class getter not serialized to the client
JSON, so the "expired" badge never showed — compute expiry in the view via
`Date.now() > Number(expires_at)`. Also guard the `last_used_on: 0` / falsy
case (string "0" is truthy) so unset timestamps render "—" not "1970".
- middleware/auth.js: authIO did `checkToken(socket.handshake.auth.token || 0)`,
so any socket connect without a token (login page, pre-login) did an
`AuthToken.get(0)` lookup and logged a noisy `EntryNotFound` trace. Guard:
reject the socket with a generic 401 when there's no token (behavior-
preserving — unauth sockets were already rejected; just no Redis lookup / 404).
Co-authored-by: Claude <noreply@anthropic.com>
Personal access tokens so scripts/CI can call the management API without a
browser session. Each logged-in user mints their own token; it authenticates as
the creator (carries their LDAP group permissions, re-resolved live), so the
existing permission.byGroup checks apply unchanged.
- models/api_token.js: new ApiToken model (sso_<id>_<secret> format; id is the
lookup key, secret bcrypt-hashed + isPrivate, shown once). add()/rotate()/
authenticate(); optional expires_at; best-effort last_used_on. No _ttl
(persists; lifetime via expires_at).
- routes/api_token.js: self-service CRUD (list/get/update/delete/rotate),
owner-scoped (created_by === req.user.uid, 403 otherwise).
- middleware/auth.js + models/auth.js: accept `Authorization: Bearer sso_...`
(precedence over the auth-token session header); checkApiToken collapses
every failure to one generic 401 (no existence/secret/expiry leak).
- views/api_tokens.ejs + routes/index.js (GET /api-tokens): self-service page
(forceLogin, no group gate) — create (token shown once), edit, rotate, revoke.
- views/top.ejs: "API Tokens" nav entry visible to all logged-in users.
- public/js/app.js: app.apiToken client module.
- DEPLOYMENT.md + docs/deployment.md: API tokens section.
Co-authored-by: Claude <noreply@anthropic.com>
wmantly
