bitborg/bitborg-docs
Bevaka
2
0
Avgrena
Du har redan avgrenat bitborg-docs
 0
Kod Ärenden 16 Ändringsförfrågningar Projekt 1 Aktiviteter Actions

The path into the service: sign-up, the anti-spam check and sign-in wayfinding #69

Nytt ärende
Öppen
öppnade 2026-08-02 12:24:12 +00:00 av supernaut · 0 kommentarer
supernaut kommenterad 2026-08-02 12:24:12 +00:00
Ägare
Kopiera länk

Everything between "I want an account" and "I am signed in and working" — the sign-up form, the
anti-spam check, and the wayfinding between the portal, the identity provider and the git host.

Several independent gaps, all on the same path:

  • The anti-spam check is the only control on the sign-up form without a native constraint. Every
    other field has required, pattern or type="email", so the browser blocks an incomplete
    submit. The check does not, so an unsolved check is the one thing that lets the form leave the
    page — and the response is a fresh, empty form, because nothing is echoed back and the page is
    no-store. It looks like the check wipes the form.
  • With JavaScript off, sign-up cannot succeed at all. The token field is created at runtime and
    the solver is WebAssembly. Today the only way to learn this is to submit and be told the check
    failed.
  • The check explains nothing. A visitor who has met the usual third-party image puzzles has no
    way to know this one is self-hosted, image-free and tracking-free — a point in our favour we are
    keeping to ourselves.
  • A visitor with no account who reaches the sign-in page is stranded. Local registration on the
    git host is disabled, so clicking "Sign In" leads to a username prompt with no route to account
    creation. The identity provider has no configuration for this and its stylesheet hook cannot
    produce a clickable anchor; the fix belongs in the git host's navbar, where a supported template
    hook already exists.
  • The password path silently costs more than it appears to. Every person already requires MFA by
    account policy, and a passkey satisfies that policy alone — so a passkey user never sees a
    second-factor prompt, while a password user must additionally enrol an authenticator app. Both are
    currently presented as an even choice.
  • Losing an authenticator has no self-service answer, although backup codes are supported by the
    identity provider today and need no server change — they are simply undocumented.

Decision taken

A clickable link on the identity provider's sign-in page is not a hard requirement. The fix goes
in the git host's navbar, where an anchor is supported, plus a plain-text pointer on the sign-in
page for people arriving by bookmark or email. No body-rewriting is added at the TLS edge.

Scope

Done when

A visitor can get from any entry point to a working account without retyping a form, without
guessing a URL, and without discovering a requirement by failing.

Status — 2026-08-02

Three of ten. The two that matter most for a first arrival are live: an unsolved anti-spam check no
longer clears the form, the check explains itself in both languages, and a signed-out visitor on the
git host is now offered account creation — in their own language, pointing at their own locale's
sign-up page.

The remaining seven are the deeper half of the path, and none is blocked:

  • #164 needs the draft-cookie privacy decision before it can start.
  • #166 / #167 are the passkey-first steering and the backup-codes documentation — the two
    changes that would actually reduce onboarding friction, both copy-only.
  • #338 now has more to work with: set-allow-account-recovery was found enabled in production
    with no mail sender behind it, and has been disabled. Adopting the native flow means deploying
    kanidm-mail-sender first, with the ADR 0011 sovereignty question answered.
Everything between "I want an account" and "I am signed in and working" — the sign-up form, the anti-spam check, and the wayfinding between the portal, the identity provider and the git host. Several independent gaps, all on the same path: - **The anti-spam check is the only control on the sign-up form without a native constraint.** Every other field has `required`, `pattern` or `type="email"`, so the browser blocks an incomplete submit. The check does not, so an unsolved check is the one thing that lets the form leave the page — and the response is a fresh, empty form, because nothing is echoed back and the page is `no-store`. It looks like the check wipes the form. - **With JavaScript off, sign-up cannot succeed at all.** The token field is created at runtime and the solver is WebAssembly. Today the only way to learn this is to submit and be told the check failed. - **The check explains nothing.** A visitor who has met the usual third-party image puzzles has no way to know this one is self-hosted, image-free and tracking-free — a point in our favour we are keeping to ourselves. - **A visitor with no account who reaches the sign-in page is stranded.** Local registration on the git host is disabled, so clicking "Sign In" leads to a username prompt with no route to account creation. The identity provider has no configuration for this and its stylesheet hook cannot produce a clickable anchor; the fix belongs in the git host's navbar, where a supported template hook already exists. - **The password path silently costs more than it appears to.** Every person already requires MFA by account policy, and a passkey satisfies that policy alone — so a passkey user never sees a second-factor prompt, while a password user must additionally enrol an authenticator app. Both are currently presented as an even choice. - **Losing an authenticator has no self-service answer**, although backup codes are supported by the identity provider today and need no server change — they are simply undocumented. ## Decision taken A clickable link on the identity provider's sign-in page is **not** a hard requirement. The fix goes in the git host's navbar, where an anchor is supported, plus a plain-text pointer on the sign-in page for people arriving by bookmark or email. No body-rewriting is added at the TLS edge. ## Scope - [x] gitborg/gitborg-web#162 — block submission on an unsolved anti-spam check instead of clearing the form - [x] gitborg/gitborg-web#163 — describe the check, and say plainly that it needs JavaScript - [ ] gitborg/gitborg-web#164 — preserve typed values when the server rejects a submission - [x] gitborg/gitborg-infra#336 — offer account creation to signed-out visitors on the git host - [x] gitborg/gitborg-web#165 — say where to create an account when sign-in is all that is on screen - [ ] gitborg/gitborg-infra#337 — ask upstream for a configurable link on the sign-in page - [ ] gitborg/gitborg-web#166 — make passkey the primary choice and name the cost of the password path - [ ] gitborg/gitborg-web#167 — document backup codes - [ ] gitborg/gitborg-infra#338 — decide between portal-driven and native account recovery - [ ] gitborg/gitborg-infra#339 — "Kanidm cannot send mail" is stale as of 1.10.4 ## Done when A visitor can get from any entry point to a working account without retyping a form, without guessing a URL, and without discovering a requirement by failing. ## Status — 2026-08-02 Three of ten. The two that matter most for a first arrival are live: an unsolved anti-spam check no longer clears the form, the check explains itself in both languages, and a signed-out visitor on the git host is now offered account creation — in their own language, pointing at their own locale's sign-up page. The remaining seven are the deeper half of the path, and none is blocked: - **#164** needs the draft-cookie privacy decision before it can start. - **#166 / #167** are the passkey-first steering and the backup-codes documentation — the two changes that would actually reduce onboarding friction, both copy-only. - **#338** now has more to work with: `set-allow-account-recovery` was found enabled in production with no mail sender behind it, and has been disabled. Adopting the native flow means deploying `kanidm-mail-sender` first, with the ADR 0011 sovereignty question answered.
supernaut lade till detta till projektet Bitborg Roadmap 2026-08-02 12:27:12 +00:00
Logga in för att delta i denna konversation.
Ingen gren/etikett specificerad
Grenar Taggar
main
Inga resultat hittades.
Etiketter
Rensa etiketter
  
area/backups
Backup & restore

  
area/ci
Actions / runners

  
area/control-panel
Logged-in self-service area

  
area/identity
Kanidm / OIDC / entitlements

  
area/infra
Infrastructure (OpenTofu/Ansible/host)

  
area/observability
Monitoring / logs / analytics

  
area/payments
Billing / payment providers

  
area/security
Security & compliance (incl. ISO 27001)

  
area/storage
Volumes / data / LFS

  
area/web
Public web portal (gitborg-web)

  
blocked
Evaluated and specified, but waiting on an external dependency

  
needs-info
Waiting on the reporter for more information

  
needs-triage
Not yet evaluated

  
ready-for-implementation
Fully specified, ready to be picked up

  
type
bug
 Something is broken

  
type
chore
 Maintenance / housekeeping

  
type
docs
 Documentation

  
type
epic
 High-level roadmap item

  
type
feature
 New capability

  
type
task
 Concrete unit of work

  
wontfix
Will not be actioned

Inga etiketter
area/backups
area/ci
area/control-panel
area/identity
area/infra
area/observability
area/payments
area/security
area/storage
area/web
blocked
needs-info
needs-triage
ready-for-implementation
type
bug
type
chore
type
docs
type
epic
type
feature
type
task
wontfix
Milstolpe
Rensa milstolpe
Inga objekt
Ingen milstolpe
Projekt
Rensa projekt
Inga objekt
Inget projekt
Bitborg Roadmap
Tilldelade
Rensa tilldelade
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Förfallodatumet är ogiltigt eller utanför gränserna. Använd formatet "åååå-mm-dd".

Inget förfallodatum satt.

Beroenden

Inga beroenden satta

Referens
bitborg/bitborg-docs#69
Ingen beskrivning angiven.