fix: transfer return to url between flows #326
Conversation
|
I'm not sure, but you might be doing work that i'm currently doing / have already done (which is fixing a lot of these edge cases): #321 |
| const initFlowUrl = useCallback( | ||
| (flowType: FlowType) => { | ||
| let query = "" | ||
| if (flowContainer.flow.request_url) { |
There was a problem hiding this comment.
The request_url and the flow type can differ here. For example, you call initFlowUrl() of Login but you are currently in a registration flow. Taking the query params from e.g. login to registration may or may not cause issues (e.g. using a parameter that doesn't exist or with an invalid value).
You can check on the PR I made - utils/urls.ts where we have initFlowUrl (usually for transitions) and restartFlowUrl (to restart the flow with the same params).
I think it's good to expose both variants to users as they're quite useful
There was a problem hiding this comment.
Ah, true.
This helper was just intended to transfer the return to (to preserve oauth context, etc.).
None of the functions in utils/urls.ts are exposed at the moment, though.
There was a problem hiding this comment.
This helper was just intended to transfer the return to (to preserve oauth context, etc.).
Understood, just wanted to highlight the difference in case you decide to port these changes over.
None of the functions in utils/urls.ts are exposed at the moment, though.
I often do that on purpose because "when in doubt leave it out" - if no-one is asking for them to be exported we shouldn't export it, because it makes it more difficult to do changes later on. I do agree though that those are helpful functions to have
Related Issue or Design Document
Checklist
If this pull request addresses a security vulnerability,
I confirm that I got approval (please contact [email protected]) from the maintainers to push the changes.
Further comments