Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Identity: finish standing and confirmation-age recovery evidence (S4/S2)

Aperta
#490 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Zamojski5 ci sta già lavorando.

Dal 12/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Part of #311 (F-024 S4), with the existing #312 S2 acceptance carried forward. Milestone 2: Flux — complete application and release. #392 is a bounded implementation slice; #311/#312 remain open until their complete criteria and test rows pass. This child carries existing requirements, not new feature scope or a SQL reservation.

Implementation owner: @Zamojski5. Independent evaluator: @PelikanFix16.

Existing work and dependencies

#384 is protected-main 7babb7ef9a7d0f9ed48d7dae186a7aa3739dc0ea; its immutable S1 family facts must survive. #395 was merged into #392's branch and its S2 implementation must not be recreated. #418 is the existing owned S3/back-channel child of #392; preserve #314 and that child's scope/ownership. #315 already owns exclusive modes, migration/claim adapters and re-key recovery; #483 already owns incomplete S1 Keycloak/client evidence. Link shared evidence to those records instead of duplicating their implementations.

The governing contract is F-024 MCPID-5 and Docker test plan, including N1/N3/N5 and test cases7–9. Retain its original criteria verbatim:

S4 — Standing check
  • AC-1. offline_access at sign-in. The IdP refresh token is stored encrypted in
    its own table, with its sid. The replaced token is revoked at the IdP only when
    no live Flux browser session carries its sid (and it is not the new sign-in's
    sid); otherwise it is forgotten and left to the IdP's offline idle limit.
    This is the accepted conditional-replacement contract integrated in #418.
  • AC-2. The check runs in api and claims identities with FOR UPDATE SKIP LOCKED inside one short leasing statement; no lock or transaction is held across the
    IdP call (N3). It has success, sign-in required and unknown outcomes; a rotated token
    is stored before the previous one is forgotten; no stored token means sign-in
    required. A sign-in that returns no refresh token is refused (N1). Checks continue
    for a suspended identity and a later success clears the state (N5).
  • AC-3. Sign-in required deletes the browser sessions, answers MCP requests with
    401 and an RFC 6750-safe error_description, refuses refresh, and revokes
    nothing. A new sign-in restores use of kept refresh tokens and grants.
  • AC-4. Standing gates every /mcp bearer, run-token minting and the start of
    owner compute (O-007, O-008; F-022 runs when they are built).
  • AC-5. Backups leave out the token table's rows; after a restore, managed
    identities are in sign-in required. No IdP token is in exports or logs.
  • AC-6. The Keycloak disable, delete and offline-session rows and the
    automation row of test case 7, and the lost-rotation row of case 9.
S2 — Confirmation age
  • AC-1. A managed account's browser sessions, MCP refresh grants and MCP
    requests are refused past FLUX_OIDC_CONFIRMATION_MAX_AGE, with the stated
    error and message.
  • AC-2. Re-authorization preselects the client's existing connection.
  • AC-3. Unmanaged accounts keep today's lifetimes.
  • AC-4. The confirmation-age rows of test cases 7 and 9.

Delivered fragments and remaining outcomes

#392's actual author behavior pin a83d1e40db8e8131c55b8d2ffb2aa9723d894962 records targeted API33 and Keycloak/mock32 passing. The current public draft cd41fbd4076e802730073886ab5c7d18d2209e39 composes protected main 7babb7ef9a7d0f9ed48d7dae186a7aa3739dc0ea, retaining all current-main SQL (including immutable 66/83/86 facts) plus original 70/71, operator env examples and accepted Settings composition. Current setup, 120 foundation tests and both required CI checks pass. No new Docker behavior run is claimed; earlier results retain their original pin and do not establish complete S4/S2 acceptance.

Existing fragments include sealed per-person/provider AES-GCM/HKDF token custody, replacement revocation, short leases/timeout/batch/concurrency, no lock across refresh, stored-state gates, invalid_grant suspension without revocation, unknown retries, suspended identity recovery, provider-change reconciliation and no-token startup refusal. S2 confirmation parsing/newest-time choice, browser/MCP/refresh age refusal, unmanaged controls and held-connection reauthorization exist. Keep those real assertions; do not weaken them.

Remaining work/evidence:

  • Automation-only and active automation: an identity with owner compute but no live browser session/MCP refresh is still selected and checked. Enforce every required personal/proactive/server/runtime pre-read/dispatch/commit and run-token mint/accept gate. Prove disabled/removed-owner refusal and recovery under still-live consent/grants without granting another owner/payer authority. The current claim query deliberately selects only browser/MCP-active identities; adapter wiring alone is not full AC-4/6 delivery. Conditional F-022 criteria remain open when their real token/run path is available, not marked done from an ordinary OAuth bearer.
  • Refresh profile/claims: verified name/email updates from returned ID-token claims follow the existing selected-provider rules, preserve issuer/subject and old grant authentication facts, and keep the recorded collision skip/log behavior. Missing or invalid claims cannot transfer accounts, widen grants or rewrite original family provenance. Coordinate adapters with #315; do not implement a second provider collection or claim real-provider compatibility from mocks.
  • Remaining test rows: real Keycloak user deletion and removal of Flux's existing offline access/session; N1 missing-refresh refusal; the specified lost-rotation response and successful previous-token retry, unknown503/timeout/invalid_client behavior composed with the age limit; standing-off confirmation-age behavior and reauthorization; automation row and refusal controls. The existing client use.refresh.tokens=false sign-in test does not prove removal of an already held offline authorization.
  • Genuine recovery/custody integration: populated protected-main90 → ordinary CLI upgrade adding late70/71, preserved native data/files/66/83/86 family facts and exact ledger/restart; real backup with a nonempty sealed-token table omits its rows and all IdP secrets from dump/export/log/response evidence; actual restore/start refuses managed browser/MCP/refresh use until a genuine provider sign-in restores the retained connection/grants. Supplemental synthetic SQL/repository fixtures cannot replace this operator path.

Acceptance and handoff

Run app/toolchain/Keycloak/SQL/client checks only in Docker on isolated projects/volumes/ports, one heavy lease at a time. Use the smallest affected maintained selectors plus genuine bounded operator/recovery fixtures; preserve each original refusal and positive control. Record each S4/S2 criterion/test row as pass/fail/unverified with the exact head and actual counts. Mocks prove their declared behavior only; real vendor journeys remain #483. Keep source/config/runner/image correspondence, required CI and eligible independent current-head approval. Missing checks or scope fragments never close #311/#312 or satisfy v0.1 acceptance. Zamojski5 owns the remaining implementation under this child; PelikanFix16 independently evaluates it. This handoff creates no parallel writer on the preserved historical branches.

Ownership boundary for this handoff

At the user's explicit request, the remaining S4/S2 work in this issue is handed to Zamojski5, alongside the existing #483 S1 integration work. The original S4 AC-2–AC-6 and S2 AC-1–AC-4, test rows and authority boundaries are unchanged. S4 AC-1 above is synchronized with the accepted token-sid and conditional replacement rule in merged #418.

The current-confirmation repair for already-open map/wiki channels remains owned by PelikanFix16 in existing PR #389 (codex/228-main-composition). Do not edit that branch or duplicate that repair. Its confirmation-age requirement remains part of S2 AC-1 and integrated acceptance: reference and compose the independently accepted #389 result when available; it is not waived or counted as completed by this handoff. Other remaining S4/S2 automation selection, standing gates, profile/claims, private/recovery/outage/rotation and conditional run-token outcomes stay here. #483 retains real S1/provider/vendor-client evidence; #315 retains exclusive modes, migration/claim adapters and re-key recovery. Share pinned evidence without duplicating their implementations.

Preserve the historical claude-hubert/311-idp-standing-check and claude-hubert/312-grant-confirmation-age branches/worktrees. Continue on a dedicated owner-controlled claude-maurycy/490-standing-confirmation branch from protected main, with one writer and a fresh PR evaluated by PelikanFix16. Existing requested fixes to #494 and #462 take priority; #490 is a ready follow-on within the existing WIP queue, not authorization for an extra simultaneous implementation or another task.

Lingua principale
TypeScript
Stelle
3
Fork
0
Merge medio
18h 3m
PR unite (30g)
254

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ColdPhase/flux

Tutte le issue di ColdPhase/flux

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.