Redirect to the initial requested URL including Query parameters

Help
,
1

I implemented the login of the application based on the provided vanilla PHP-SDK Sample which works like this:

  • User tries to open a page of the application which is only accessible to logged in users, let’s say /home.php?topic=test&revision=12
  • Check for $auth0->getInfo()
  • If no user loggedin redirect to a login.php page and send the accessing url along (e.g. redirect_to=home.php?topic=test etc. (of course encoded)
  • From there perform the actual login through auth0->login() with the redirect_uri specified to the query-parameter value of redirect_to

It usually works like a charm, but while using sign in with google after redirection all the & chars are encoded to &amp%3B

One workaround for this was to check in the url for those &amp%3B and redirect the user to an url where those are actually replaced with ?. But this seems like a very hacky approach and so I’m wondering if there is a different way of achieving something like that through the SDK alltogether. Is there maybe a specific auth0-concept which I’m missing to achieve that? Or do I have to stick to that hack?

2

Hey @irtech :wave: I’m not sure if we have best practice advice published expressly against using parameters with redirect_uris, but it’s fraught with potential for issues like this as encoded strings get passed around between endpoints. Better off avoiding using params there.

My suggestion would be to set a cookie or PHP session key for the user’s device prior to issuing the login redirect — something you can safely store on your app’s end and pull up when the user returns from the authentication flow to your callback route, etc. Set the value (complete with those request params you want) to where you want to bounce the user to after they’re returned to your app’s callback from the Auth0 flow completing. When they hit your app’s callback, pull that stored key you made, and issue a redirect to that stored value location.

Alternatively, if the string doesn’t end up being too long, you could encode a custom ‘state’ that includes that information, so it’s returned to you after the flow as the state param, can then decode it, and use that - but setting something on your app’s end with a cookie or session would be a bit more resilient to issues, I think. This would be more appropriate if you’re writing a stateless app, like an API.

There are a few good docs I found that offer guidance on this sort of approach:

1 Like
3

Thanks @evansims for following up on that!

1 Like
4

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.