Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#607 0 bình luận 1 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
22/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
nextjs, react, typescript
Lĩnh vực
authentication, frontend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
187
Fork
80
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ory/elements

Tất cả issue của ory/elements

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.