Open alexandrebrg opened 2 years ago
Thank you for the report, where would you like to redirect the user to instead? We redirect them to the settings page as users probably want to update their credentials when recovering the account. If I’m not mistaken, the post-recovery redirect triggers once one updates their settings successfully
In our current application, the settings flow is used in two pages (due to UX concerns):
That's why we expect the user to be redirected to a different page than the settings flow page. We do not expect to be on settings page after clicking on recover link. Moreover, I tried to edit my settings after having completed the recovery flow, and it did not redirect to recovery.after.default_browser_return_url
as you stated
I see, it’s possible that the final redirect doesn’t work yet.
Regarding the update, it should be possible (e.g. by checking the messages) to identify that a settings flow is initiated by recovery, you can then filter out all the irrelevant fields in the UI!
You are right, the settings flow has a message when created by recovery flow.
About the issue, I understood that after
keyword should be used as a redirect after completing the settings flow generated by the recovery. Our application is an SPA, so we expected the user to be redirected while clicking on recovery link.
After thinking about it, I can't confirm that your statement about final redirection is false, as we don't redirect the user after settings flow submission (XHR calls). This final redirection isn't documented, so I guess some details about recovery flow can be added (I can spend time to it if needed). Also, the final redirection needs to be tested to ensure it works, and that this issue can be closed as it's not a bug.
We can keep it open until your issue has been resolved :) For SPAs, we usually indicate redirects with a specific error type that indicates that a redirect is required. However, for success flows we just return 200 OK as it’s up to the app to decide what to do. Most SPAs for example choose to show some type of flash message using the tooling of their choice - so yes, it’s completely possible that we do not indicate the redirect properly. I’m wondering however how we could do that? If you have any ideas please let us know :)
Just bumped into this as well on Kratos 1.0.0. I'm using the recovery flow to generate invite links, and would like to control the destination URL the user is redirected to after they click the invite link.
I tried setting recovery.after.default_browser_return_url
and adding a return_to
query parameter to the recovery URL, but in both cases I was redirected to the settings page. Is there any way to control the redirect destination?
Bumping this as I'm in the same situation as @chromakode
Same here !
It would be nice to have both an intermediary redirect (after the user clicks the invite link, or successfully submits the recovery code that they received by email) and a final redirect that works (after the user successfully changes their password. At the moment I believe the final redirect does not work either as per my tests and I'm not sure which default_browser_return_url
it will default to).
Thank you and keep up the amazing work please !
[Edit]
I was able to make the final redirect work by setting the selfservice.flows.recovery.after.default_browser_return_url
or by specifying a returnTo thanks to the sdk
ory
.createBrowserRecoveryFlow({
returnTo: String(returnTo || ""),
})
Couldn't find a way for the intermediary redirect though.
Preflight checklist
Describe the bug
On a self-service instance of Kratos, using http redirects, we can add
selfservice.flows.<login[registration|recovery...>.after.default_browser_return_url
to redirect the user after completing a flow. It works properly for flows likelogin
orregistration
but doesn't forrecovery
flow.As explained in documentation, a successful recovery does a HTTP 303 redirect to a settings flow, however we can't override it.
Reproducing the bug
${kratos_ui_settings}
instead of${kratos_ui_recovery_redirect}
Relevant log output
No response
Relevant configuration
Version
v0.8.0-alpha.3
On which operating system are you observing this issue?
Linux
In which environment are you deploying?
Kubernetes with Helm
Additional Context
Kratos version is
v0.8.0-alpha.3
, but after discussing with David Alexandre on Slack, it is the same on latest version.