---
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: progress
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.

Diagnosis, 2026-09-24. This is an upstream Authelia defect.
`internal/authentication/ldap_util.go` `ldapEscape()` in v4.38.0 through
v4.38.19 (the last 4.38 release) and in v4.39.0 applies `ldap.EscapeFilter`
and then DN-escapes `, # + < > ; " =` as `\c`. Inside a filter, an escape
must be `\XX` hex, so the go-ldap filter compile fails for any username or
email containing one of those eight characters. v4.39.28 (2026-09-17) builds
the filter with `ldap.EscapeFilter(input)` only (`ldap_user_provider.go:720`).
No configuration workaround exists.

Upgrade prepared. The target is `authelia/authelia:4.39.28`, pinned as
`sha256:bd97cff4…`. The live image is the floating tag `4.38`
(`sha256:46021dc2…`). The live `authelia-config` was validated locally with
placeholder secrets under both versions: each returned exit 0 with no errors
and the same set of auto-mapped deprecation warnings. Storage is SQLite on
the PVC, and 4.39 migrates the schema on start. The rollback therefore needs
the pre-upgrade copy (`backups/db.sqlite3.pre-4.39.28`) as well as the old
digest. The daily backups continue.

## 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.