Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

elements-react: settings success toast is lost when return_to is set; need a supported hook to influence the post-submit redirect

Abierto
  • ¿Algo no está bien?
#607 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
22/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
nextjs, react, typescript
Área
authentication, frontend

Línea de trabajo

Start in onSubmitSettings.ts, where onSuccess runs before handleContinueWith, and read how handleContinueWith and setFlowContainer decide between redirecting and updating the flow. SettingsMessageToaster is the component that reads flow.ui.messages. The issue offers three options (an onSuccess return value, exposing onRedirect on the provider, or documenting the mutation contract), so a maintainer must pick one before code. Done means that a settings save with return_to shows the success toast under the chosen contract, with a test.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Needs Triage

Summary

@ory/elements-react: when a settings flow is initialised with return_to, a successful save never shows the success toast. The only way to keep the toast today is to mutate the flow object inside onSuccess, which works but is not a documented contract. Request: a supported hook for influencing where Elements goes after a successful submit.

Tested on @ory/elements-react 1.2.1 and current main, Next.js 15 app router, Ory Network.

What happens

onSubmitSettings.ts:

const body = await res.value()
await onSuccess?.({ flowType, method, flow: body })
const didContinueWith = handleContinueWith(body.continue_with, { onRedirect })
if (didContinueWith) return
setFlowContainer({ flow: body, flowType })

On browser JSON requests Kratos always attaches continue_with: [{ action: "redirect_browser_to", redirect_browser_to: <return_to> }] on success (selfservice/flow/settings/hook.go, NewContinueWithRedirectBrowserTo(returnTo)), and redirect_browser_to is the raw return_to with no flow= appended. So with return_to set, handleContinueWith always redirects and setFlowContainer is never reached. SettingsMessageToaster reads flow.ui.messages from the rendered flow, so the "Your changes have been saved!" toast never fires. It only shows when Kratos falls back to settings_ui_url?flow=<id> (no return_to).

Any app that uses return_to to carry page state through the settings flow (multi-brand query params, deep links back into the app) loses success feedback.

What people do today

Two workarounds, both verified live:

  1. In onSuccess, stash flow.ui.messages (session storage or router state) and render it after the redirect.
  2. In onSuccess, mutate continue_with: append flow=<completed id> to the redirect_browser_to entry that equals flow.return_to. Elements then redirects to <return_to>&flow=<id>, the page fetches the completed flow (state: success, ui.messages present), and the built-in toast shows.

Option 2 is what a customer has in production. It works only because onSuccess receives the same object by reference that handleContinueWith reads afterwards, and because the callback is awaited first. Neither is documented; the onSuccess docs say "invoked after a successful submission, before the default behavior (redirect, flow update)". A refactor that clones the flow, freezes it, or reorders the two calls silently breaks it.

Request

One of, in order of preference:

  1. Let onSuccess return a value that overrides the default behaviour, e.g. { redirectTo?: string; continueWith?: ContinueWith[]; preventDefault?: boolean }. Keeps the existing event shape; by-reference mutation becomes unnecessary.
  2. Expose onRedirect on <Settings> / OryProvider (it is already a parameter of onSubmitSettings and the nextjs package has useOnRedirect), so apps can intercept the redirect_browser_to target.
  3. If neither: document that the flow passed to onSuccess is the same object handleContinueWith reads and that mutations are honoured, and add a test so it stays that way.

Also worth noting in the onSuccess docs that with return_to set the toast does not show, with a pointer to the workaround.

Repro

  • Project with settings.ui_url = <app>/settings, <app> in allowed_return_urls.
  • Open <kratos>/self-service/settings/browser?return_to=<app>/settings?brand=x.
  • Save the profile form. Observe: redirect to <app>/settings?brand=x, new flow started by the page, no toast.
  • Add onSuccess={(ev) => { for (const cw of ev.flow.continue_with ?? []) if (cw.action === "redirect_browser_to" && cw.redirect_browser_to === ev.flow.return_to) cw.redirect_browser_to += "&flow=" + ev.flow.id }}. Observe: redirect to <app>/settings?brand=x&flow=<id>, toast shows.

Console from the second case:

[onSuccess] {"state":"success","messages":[{"id":1050001,"text":"Your changes have been saved!","type":"success"}],
  "continue_with":[{"action":"redirect_browser_to","redirect_browser_to":"http://localhost:3000/settings?brand=blick&flow=31b5031e-…"}]}

Side note observed while testing: because ui.messages stays on the completed flow, reloading ?flow=<id> shows the toast again. Same as Kratos' own default redirect, so probably fine, but a consumer-side "mark as seen" would need the hook above too.

Lenguaje dominante
TypeScript
Estrellas
187
Forks
80
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ory/elements

Todos los issues de ory/elements

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.