gotrue: redirectTo either ignored or stripped of /#/
Problem
I am getting unexpected behavior using the redirectTo in gotrue-dart (I added it through a PR). The URL is constructure with &redirectTo=<url>.
I have 2 scenarios.
SiteUrl: https://someapp-something.codemagic.app/#/
redirectTo: http://localhost:3000/#/
Redirects to: https://someapp-something.codemagic.app/#/
SiteUrl: http://localhost:3000/#/
redirectTo: http://localhost:3000/#/
Redirects to: http://localhost:3000/
In both cases I would want it to redirect to http://localhost:3000/#/ including /#/.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 2
- Comments: 20 (10 by maintainers)
Commits related to this issue
- fix: URL encode redirectTo Fixes https://github.com/supabase/gotrue/issues/90 — committed to nstrelow/gotrue-dart by nstrelow 3 years ago
- fix: URL encode redirectTo (#15) Fixes https://github.com/supabase/gotrue/issues/90 — committed to supabase/gotrue-dart by nstrelow 3 years ago
@awalias This part is working now as expected ^^. Redirect to
http://localhost:3000/#/I was able to fix it, by encoding the url parameterredirectTo. I previously added redirectTo support to the gotrue-dart SDK, so I introduced the feature and bug. Sorry for that.Now it is fixed
@icecream78 I think I have to apologize. I added the redirectTo option to the dart SDK. And I did not encode the URL to use it as a parameter. So probably that URL escaping messed it all up. Sorry and thanks for investigating.
With that my stuff seems to work now. Will upload a fix soon.
PS: What @emschwartz suggests sounds sensible, if there is no case where somebody would not control a domain but only a path on it.
@awalias yeah. I’ll look on it
@nstrelow no problem. I’m glad that I helped you=)
Does that mean that the full URL, including the path, needs to be in the allowed list in order for it to work?
If so, would it be possible to change it to only look at the domain? That would allow redirecting to pages with dynamic paths. It also shouldn’t be any different from a security perspective because all of the paths are under the control of whoever controls the domain.
@nstrelow please add extra info about your problem. Have you inserted your redirect_uri in settings?
Because I’ve checked flow with generating magic link + verification it and Gotrue redirected me by provided redirectTo field’s value correctly
@icecream78 do you want to take a look at this one? we need to make sure
redirect_totakes priority overRedirectHeader if setAny chance this will be able to get fixed?
Thanks for the hard work and all, don’t feel pressured ❤️
I think the server may be overwriting
redirectTowith the value passed by the browser in therefererheader (in this case presumablyhttp://localhost:3000/this is a bug, we should prioritize
redirectToif it’s set