Expose error/status callbacks on the prebuilt <SignIn /> component (e.g. incorrect password, rate limiting)

Aperta
#9,770 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
react, typescript
Ambito
authentication, frontend

Direzione di ricerca

Inizia dal punto di ingresso predefinito in @clerk/clerk-react e traccia il modo in cui l'invio del modulo interno gestisce gli errori. Esamina come vengono rappresentati ClerkAPIError[] e codici come form_password_incorrect e too_many_requests, quindi determina il comportamento del callback e la copertura necessaria per i tentativi di accesso non riusciti.

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

Descrizione

Is your feature request related to a problem?

The prebuilt <SignIn /> component (@clerk/clerk-react) handles the full sign-in flow internally but doesn't expose any way to observe failures — incorrect password, rate limiting (429s), locked accounts, etc. There's no onError prop, no emitted event, and no documented way to read the failure reason from useSignIn() when the failure happened inside the component's own internal form submission (not one we drive ourselves).

As a workaround, we've had to monkey-patch window.fetch to sniff HTTP status codes for requests to our Clerk FAPI domain, just to detect a 429 and show a "too many attempts, retry in Ns" banner:

window.fetch = async (...args) => {
  const response = await originalFetch(...args);
  if (url.includes(CLERK_DOMAIN) && response.status === 429) {
    // surface a rate-limit banner
  }
  return response;
};

This is fragile (breaks on any internal FAPI change), duplicated per-app, and can't distinguish error reasons (wrong password vs. locked vs. rate-limited) — only status codes.

Describe the solution you'd like

An onError (or onStatusChange) prop on <SignIn /> that fires with Clerk's structured error info (e.g. ClerkAPIError[] with codes like form_password_incorrect, too_many_requests) whenever an internal sign-in attempt fails — without requiring us to reimplement the form via the headless useSignIn() hook just to get error visibility.

Describe alternatives you've considered

  • Rebuilding the whole sign-in form with useSignIn() to get error access — loses all the built-in UI/appearance theming <SignIn /> gives us for free.
  • Patching window.fetch — fragile, non-public API surface, no error-code granularity.

Happy to contribute a PR if maintainers can point at the right place to emit this.

Lingua principale
TypeScript
Stelle
1.8k
Fork
472
Merge medio
2g 15h
PR unite (30g)
193

Guida per i contributori

Apri la guida per i contributori

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 clerk/javascript

Tutte le issue di clerk/javascript

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.