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

Follow-up hardening after the account-adoption gate (GHSA-vf58 / 2.6.0)

Aperta
  • Qualcosa non va?
#231 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 5 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
authentication, backend, security

Direzione di ricerca

L’issue non indica alcun file; inizia separando i sei filoni di hardening e leggendo la risoluzione delle sessioni nel core, il middleware delle richieste del plugin, onLogin/getUserInfo e l’integration harness descritto in #230. Conferma quale filone non è ancora assegnato, poiché il lavoro sulla hook-provenance ha già una prima PR. Il lavoro è concluso quando il comportamento selezionato è coperto da test, inclusi i casi rilevanti di fail-closed o authenticated-source.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Follow-up hardening after the account-adoption gate (2.6.0 / GHSA-vf58-5v5f-mvpm)

2.6.0 shipped the account-adoption gate: a new OAuth login adopts an existing hdb_user only when the claim is a verified email from an authenticated source (a JWKS-signature-verified OIDC id token with a validated issuer, or GitHub's authenticated email fetch). This issue tracks the hardening deliberately deferred from that release.

1. Durably neutralize pre-existing (pre-gate) sessions — incl. the operations API

The gate governs new logins. Sessions established before upgrading persist (Harper does not expire sessions by default) and may still hold a raw claim as their identity. The operations API resolves a session cookie to an hdb_user role in Harper core, on a listener the plugin's request middleware never wraps — so a plugin-level request-time check can't reach it, and a plugin-level startup sweep is only best-effort (fail-open on storage errors; a mixed-version rolling-upgrade window). The interim mitigation is documented (operator clears system.hdb_session fleet-wide on upgrade).

Proposed durable fix: a session provenance epoch in core — a marker/epoch that core's session resolution checks, so pre-gate sessions fail closed uniformly on both the app-server and operations-API paths without a per-plugin sweep. Everyone re-logs in once (same cost as clearing sessions), but fail-closed. Decision to settle: targeted plugin sweep vs. a core session epoch.

2. Expose authenticated-source provenance to onLogin hooks

A hook that returns { user } is authoritative and bypasses the gate. Today the plugin strips its provenance determination before calling onLogin, so a hook can only see oauthUser.emailVerified — which an unsigned UserInfo body can assert (email_verified: true). Expose the plugin's authenticated-source signal (and ideally validated issuer + subject) on the hook's oauthUser so hook-based deployments can gate correctly, and update the hook docs/examples to use it. (2.6.0 already corrected the docs to warn against trusting bare emailVerified.) A first PR for this is open.

3. Bind accounts by stable identity, not verified email (OIDC §5.7)

Adoption keys on the verified email matching the username and never consults (iss, sub) / a provider's stable user id. A reassigned email lets a new holder inherit the prior holder's role. Use verified email to locate a candidate account, then require a stable-identity match or confirmation for the initial binding. Accepted for 2.6.0 as email-keyed adoption; this is the follow-up.

4. Provider compatibility: explicit-endpoint configs become issuer-less

An Okta (or generic) custom-auth-server config with explicit endpoints leaves issuer empty → JWKS verifies but issuerValidated is false → hookless logins that previously adopted are denied. Derive or require the issuer for JWKS-enabled providers, and fail fast at startup with an actionable error rather than silently denying at login.

5. Smaller items
  • Reject UserInfo sub != id-token sub on the fetchEmail path (OIDC Core §5.3.2/§5.3.4).
  • Storage-error availability: a transient hdb_user read error is treated fail-closed as "account exists" → the login is denied. Secure but an availability hit; quarantining (roleless) on a read error is equally secure and more available.
  • Config-reload deeper hardening: apply the escape-hatch setting independently of the fallible provider config (or fail it closed on a reload error), so a snapshot that both disables the hatch and errors cannot leave it on. (2.6.0 fixed the drop-of-final-snapshot case.)
  • _emailProvenance label: getUserInfo stamps signed-oidc even on the no-JWKS fallback (signatureVerified === false). Not exploitable today (the gate re-checks the flags), but the label overstates its own contract for any future consumer.
6. End-to-end integration coverage

Prove the positive path end-to-end (a signature-verified JWKS OIDC token adopts an existing account and inherits its role) and the allowUnverifiedClaimInheritance escape hatch, against a real Harper instance — the current suite proves only denial/quarantine. This also needs a harness that can disable the loopback auth bypass so an operations-API denial (403) of a neutralized session is executable. Tracked in #230.

Lingua principale
JavaScript
Stelle
1
Fork
3
Merge medio
3g 8h
PR unite (30g)
11

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 HarperFast/oauth

Tutte le issue di HarperFast/oauth

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.