--- topic: ping-mee self-service portal updated: 2026-10-15T09:24 --- - (event) Create intent; coaching/fast mode not yet chosen. Stakes not yet read. - (decision) Context: ping-mee.de is the user's large homelab (Jellyfin etc.); users authenticate against homelab Active Directory (domain ping-mee.local). - (decision) Scope v1 (user words): users self-edit email, displayname, name, surname, profile picture, phone number. - (decision) Scope v1: announcement feature so admin can announce planned downtimes and changes. - (decision) Design: resembles classic Microsoft web UI. Login via LDAPS. - (event) User supplied context-resources/*.ps1: existing profile-picture pipeline (fileshare source -> AD thumbnailPhoto/jpegPhoto/photo at 96px <=100KB -> Windows logon script builds account picture sizes, 448px HQ copy from share). - (decision) Users: family and friends, ~10 people. Yet wants polished and protected 'for big deployments' (tension with right-sizing; to probe). - (decision) Pictures: portal drops files on the fileshare (existing sync task does the AD write); portal renames to .jpg if not already named so. Portal does NOT write thumbnailPhoto itself. - (decision) AD writes (other attributes): portal uses a dedicated service account with delegated privileges. - (decision) Announcements: delivered by e-mail AND shown on an announcement page in the portal. - (decision) Design: Office 365 (Fluent) look, not OWA 2010/Aero. - (decision) Stakes: homelab use first, keep option to deploy elsewhere someday (=> no hardcoded domain/OU/share paths). - (decision) Everything configurable, nothing baked in (domain, OU, paths, groups, SMTP, theme). Portal reachable from the INTERNET. No multi-domain. Admin UI wanted: upload backgrounds, change themes, settings. - (decision) Pictures: portal converts to JPEG, scales/sizes to need; user message 'updated within ~2 hours' (sync-task latency). - (decision) Writable scope: OU=Clients,OU=Organisation,DC=ping-mee,DC=local (configurable). Attributes: sn, displayName, givenName, mail, name, cn. Mail change requires confirmation e-mail. - (assumption) GAP: phone number was in the original request but is not in the attribute list (telephoneNumber/mobile?). Also name/cn are the RDN: changing needs ModifyDN, not attribute modify. - (decision) Announcements: publishers = members of a configurable AD group; SMTP server configurable (IONOS); opt-out/opt-in for e-mails wanted; one-way text primary, scheduled downtime window / severity / expiry as OPTIONAL features. - (decision) Deployment: Docker container on a Linux box. - (decision) Phone: both telephoneNumber and mobile. name and cn REMOVED from concept (no RDN renames). - (decision) Behind reverse proxy (TLS there). Login throttling wanted. Asked: authentik IdP between AD and portal as option (user has an authentik server). - (decision) Scope: ship everything (user: not a rational project, homelab is oversized by design). No phasing imposed; sequencing left to downstream. - (decision) E-mail announcements: default opt-IN; on opt-out user is told they won't get downtime notifications and can opt back in via portal. - (decision) Secrets via Docker environment variables. - (decision) NEW SCOPE: password change by users at any time (admin currently resets manually) - core success criterion. Success = no manual password resets AND one clean all-in-one package solving these homelab problems. - (decision) Password: users can CHANGE only (current+new); reset stays a manual admin process (out of scope). E-mail change requires current password + confirmation e-mail. Users with expired/must-change passwords can still log in (mechanism unresolved with OIDC). - (decision) Login via OIDC (authentik) for initial authentication only; all writes stay LDAPS with service account. Prefers OIDC over LDAPS login. - (decision) Problems solved: password change, profile info, profile pictures, announcement channel. 'Clean' = no good solution exists for these today; one all-in-one package. PowerShell scripts (sync, logon, registry) stay. - (decision) Mode: FAST PATH chosen. Draft brief with [ASSUMPTION] tags. - (assumption) Success criterion tension: forgotten passwords still need manual reset by admin, so 'no manual password work' only holds for known-password changes. - (assumption) Expired-password login: authentik/AD OIDC login likely fails for expired passwords; mechanism needs design. - (decision) Expired-password behavior with authentik unknown; to be tested. Password change confirmed: user enters current+new in portal, applied over LDAPS. - (decision) Security success criterion: no injections, no session takeover, no cross-user read/write, throttled logins. - (change) Draft v1 written: brief.md + addendum.md; security criterion made concrete, open question on expired passwords reworded. - (event) Polish pass (bmad-review structure+prose) applied; brief status set to final.