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

Most upvoted comments

@awalias This part is working now as expected ^^. Redirect to http://localhost:3000/#/ I was able to fix it, by encoding the url parameter redirectTo. 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? image

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_to takes priority over Redirect Header if set

Any 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 redirectTo with the value passed by the browser in the referer header (in this case presumably http://localhost:3000/

this is a bug, we should prioritize redirectTo if it’s set