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

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.