net-kingdom/workplans/NK-WP-0041-onboarding-journey-usability.md
tegwick e1e3905e06
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 3s
Pin identity-provisioner main-6c4fcaf (password-setup usability) as deployed
Operator-applied 2026-09-24; healthz/readyz 200, username field and
sign-in URL live. Rollback: sha256:3317a2610ef9958b77cb258dce54d69d13dfabbc55ffaad673e018f997a6467c

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 299762@bnt-lap001
Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e
2026-09-24 01:19:48 +02:00

92 lines
3.2 KiB
Markdown

---
id: NK-WP-0041
type: workplan
title: "Fix onboarding-journey defects found in the 2026-09-23 human run"
domain: infotech
repo: net-kingdom
status: active
flavor: implementation
owner: claude-code
topic_slug: netkingdom
created: "2026-09-23"
updated: "2026-09-23"
related: [NK-WP-0036, NK-WP-0037, KEY-WP-0033]
state_hub_workstream_id: "98168f50-7a4d-5bb5-a462-1e031563b89f"
---
Found by the operator's native onboarding run (NK-WP-0036-T05) and the
blocked Vergabe sign-in (NK-WP-0037-T02). Each item names its owner, and only
items in this repository are implemented here.
## Password managers and sign-in after password setup
```task
id: NK-WP-0041-T01
status: done
priority: medium
state_hub_task_id: "82ce581a-b635-5b5b-9b08-91b61e7eb9bd"
```
The setup form had no username field, so browsers stored the new password
without a login. After setup there was no way on to the sign-in page. The
source is fixed in `identity-provisioner`:
- The setup form shows the grant's login name as a read-only
`autocomplete="username"` field. The submitted value is ignored, and the
form no longer sets `autocomplete="off"`.
- The completion page links to `PASSWORD_SETUP_SIGNIN_URL` (HTTPS only)
when there is no company return. The deployment declares
`https://users.coulomb.social/`.
- The completion page still does not show the login name, as an existing
test requires.
Four new HTTP tests cover this, and the 32 provisioner tests pass.
Released on 2026-09-24. CI published `main-6c4fcaf` as
`identity-provisioner@sha256:ffacd5d7…`, and the operator applied the
declaration on railiance01. Only the image and the new env changed; the
other resources were unchanged. The new pod checks out:
- `/healthz` returns 200 and `/readyz` returns 200 (`dependency: directory`).
- An invalid setup link returns 400.
- The served code carries the `autocomplete="username"` field.
- `PASSWORD_SETUP_SIGNIN_URL` is set.
Rollback digest: `3317a261…`. The next real setup link will show the field
to a user; note it here if the password manager still misbehaves.
## Plus-addressed email sign-in fails with an LDAP filter error
```task
id: NK-WP-0041-T02
status: todo
priority: medium
state_hub_task_id: "83633649-3e5c-57e7-8207-609380a29c25"
```
Authelia's `users_filter` accepts `uid` or `mail`. Sign-in as
`bernd.worsch+99@gmail.com` failed with "LDAP Result Code 201 Filter Compile
Error: invalid characters for escape", not a clean result. A probe with fake
addresses (`nk-probe@example.invalid` compared with `nk-probe+x@…`) showed
that only the `+` form triggers the error. Establish whether Authelia 4.38
escapes `+` DN-style inside the filter, and fix it through the reference
configuration or the version. Users who use plus-addressing cannot sign in
by email until then.
## Route the portal findings to user-engine
```task
id: NK-WP-0041-T03
status: todo
priority: low
state_hub_task_id: "7350f35a-6893-5ac8-bfc5-fb2e40b3cf5d"
```
These belong to user-engine:
- The setup link is shown to the provider instead of being delivered to the
recipient (journey U04/T03: mail delivery unresolved).
- The derived login name (`bernd.worsch-99`) is not obvious to the recipient.
- There is no sign-in link from the user entry once a password has been set.
Send these to user-engine and record the reply.