0

I am making a launchWebAuthFlow authorization code request from a Chrome extension to a Rails app hosted on Heroku. Doorkeeper is an OAuth wrapper for Rails, and that is what is processing my request. More specifically Doorkeeper::AuthorizationsController#new is processing the request as HTML (why HTML?).
The forward slash (/) is missing from both the URL encoded redirect_uri and the redirect_uri shown in the rails params. The url is correct on the chrome extension side of things (unless the launchWebAuthFlow built in function is doing something to it), so I think something is happening on the server.
It works in development so I don't think anything is wrong on the extension. The app is hosted on Heroku.

Any idea of what could be going wrong here?

srlrs20020
  • 407
  • 5
  • 16

1 Answers1

0

Based from this link, Apache denies all URLs with %2F in the path part, for security reasons: scripts can't normally (ie. without rewriting) tell the difference between %2F and / due to the PATH_INFO environment variable being automatically URL-decoded.

You can turn this feature off using the AllowEncodedSlashes directive, but note that other web servers will still disallow it (with no option to turn that off), and that other characters may also be taboo (eg. %5C), and that %00 in particular will always be blocked by both Apache and IIS. So if your application relied on being able to have %2F or other characters in a path part you'd be limiting your compatibility/deployment options.

You should use rawurlencode(), not urlencode() for escaping path parts. urlencode() is misnamed, it is actually for application/x-www-form-urlencoded data such as in the query string or the body of a POST request, and not for other parts of the URL.

The difference is that + doesn't mean space in path parts. rawurlencode() will correctly produce %20 instead, which will work both in form-encoded data and other parts of the URL.

Hope this helps!

Community
  • 1
  • 1
abielita
  • 13,147
  • 2
  • 17
  • 59