kratos icon indicating copy to clipboard operation
kratos copied to clipboard

Allow overriding the redirect from the Create Settings Flow for Browsers endpoint

Open dantman opened this issue 1 year ago • 2 comments

Preflight checklist

Describe your problem

Instead of profile and password, etc... being part of the same settings page I would like to put them on separate settings pages.

However when I send a user to the "Create Settings Flow for Browsers" (/self-service/settings/browser) it always redirects to the selfservice.flows.settings.ui_url setting and this cannot be changed. As a result visiting any of the settings pages without a flow already present will always redirect to the same page.

Describe your ideal solution

Browser flow creation endpoints should accept a query parameter to tell them what UI url to redirect back to. This of course can be validated with the validations done on return_to.

There are a variety of potential names redirect_to, ui_url, flow_ui.

Workarounds or alternatives

One alternative would be to instead add an opaque state query parameter that gets passed to the UI flow either in a query parameter or in the "Get X Flow" response. Like OAuth's state parameter. This could be used to redirect to the correct place.

I have also considered essentially proxying the /self-service/settings/browser (calling it with cookies and copying the set-cookie headers) and overriding the location. But this seems unnecessarily complex.

Version

Ory Network

Additional Context

No response

dantman avatar Feb 10 '23 01:02 dantman

If I'm not mistaken, the flow payload has a request_url which has the original URL. There, you can check for additional parameters like your own show_page= parameter to filter the nodes you want to display. I think that should be a relatively quick solution that does not require a lot of coding. It's also what we suggest doing in these cases :)

aeneasr avatar Feb 13 '23 15:02 aeneasr

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

  • open a PR referencing and resolving the issue;
  • leave a comment on it and discuss ideas on how you could contribute towards resolving it;
  • leave a comment and describe in detail why this issue is critical for your use case;
  • open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

github-actions[bot] avatar Feb 14 '24 00:02 github-actions[bot]