Redirect URIs containing arbitrary parameters

[Phil Ayres]

I have been using the Bitly api through OAuth for a while. Today I needed to update a server name for an account and after making the change the https://bitly.com/a/oauth_apps page forces me to add a Redirect URI (previously this was blank).

The problem is now that I can not use arbitrary parameters in the URL query string, since the oauth/authorize endpoint returns: {"status_code": 500, "data": null, "status_txt": "REDIRECT_URI_DOES_NOT_MATCH_APPLICATION"}

Is there any way I can pass an arbitrary URL parameter through the callback? Previously I could do this:

https://bitly.com/oauth/authorize?client_id=xxxxxxxxxxxx&redirect_uri=https%3A%2F%2Fsomedomain.org%2Fbitly_api%2Foauth_callback%3Fgroup_id%3D80080

The number on the end of the URL encoded redirect could be changed to allow a special app specific identification code.

Am I now limited to adding this stuff to the session? Other apps I have where I have not yet been forced to apply a URI callback are still working, which is a good fallback, but annoying moving forward.

Any chance that there is a special escape character I could use to match old query string on my callback?

Thanks, Phil

[a...@bit.ly]

Hi Phil --

The short answer is that, no, you can't do that anymore.  (There was a security concern with having the redirect URI be too flexible.)  What we do allow is the ability to have multiple specific redirect URIs, if that helps in this situation.  

Let us know if you have any other questions.

Regards,

Andrew

[Zain Zafar]

I'd love to see this functionality coming back. Multiple specific redirects doesn't solve the problem where the redirect url contains reference to an object which is based on an autoinc id column in the database.

[ja...@bit.ly]

Storing this sort of data in a session, as Phil mentioned, is the safer choice, anyway. Users can modify the redirect_uri, it shouldn't be treated as trustworthy.

[Zain Zafar]

Instead of bit.ly, I think developers should be responsible for encrypting the variables they deem sensitive in the redirect url. In rails, we had to introduce a specific method in our root controller to get the callback and then redirect it to our internal object based on the id (which was being sent using "state"). Again, encrypting variables isn't a difficult task and should be left over to the developers for security concerns.

[ja...@bit.ly]

If we get enough feedback about this change we may consider other options. Again, I'd recommend treating `state` and any other parameters users can alter via the URL as tainted by default.