Question

Concerning https://github.com/sinatra/sinatra/issues/596, which i wrongly diagnosed as a sinatra bug.

I’m having the following issue: I’m using Soundcloud OAuth workflow to implement single-sign-on in a project of mine. For that I’m using the “soundcloud” gem. So, after being redirected to soundcloud’s sign-in/authorization form and pressing “Connect”, I’m redirected back to the URL from my app I have specified as the redirect url… but some hash parameters come behind! So, let’s say, instead of being redirected to “http://myapp.com/connect?code=123”, I am instead being redirected to “http://myapp.com/connect?code=123#access_token=qwerty”. Since hash parameters are not part of the HTTP protocol, it does have secondary effects on the server, but on the client, the bleepin hash params just do not go away! Basically, on my redirect endpoint, I’m fetching the code given by soundcloud, pinging Soundcloud’s token exchange for a fresh access token, storing it and redirecting to my homepage, ‘/’. But the browsers do not clean the hash parameters on redirects, so that means I’m being redirected to “http://myapp.com/#access_token=qwerty”. And that just sucks. Is there a workaround to this issue or is this a soundcloud “bug”? (Not exactly a bug because it doesn’t break a thing, it is just plain ugly to have those hash params there).

Answer 1

[Answered the same thing in that thread that you’ve linked but will try to summarize that here]

One reason I can think is to ensure JS cross-compatible API. That is, when using JS to authenticate the user, this is the only way to read the result of the authentication url parameters – by parsing the attributes after the # in the URL. This is as far as I can reason with the design.

And yes, there is a work-around:

Actually, the API server has more features which are not implemented directly in the Ruby driver yet. The result of the client.authorize_url call is of this type:

"https://#{host}#{AUTHORIZE_PATH}?response_type=code_and_token
                                  &client_id=#{client_id}
                                  &redirect_uri=#{URI.escape redirect_uri}
                                  &#{additional_params}"
(Ignore the `additional_params` part for now)

The response_type parameter can take other values too but unfortunately, this is not a readily-available feature in the Ruby API wrapper. The possible values are:

• response_type=code which embeds the code which can later be used to generate the access_token of the user. This can be done by running client.exchange_code(:code => params[:code]) as mentioned in the API reference docs.
• response_type=token which embeds the access_token and avoids the code parameter. However, unlike the code parameter, the access_token is not a query parameter but is prefixed with a # and so, JS is the only way to get this value.

You can verify this here: http://developers.soundcloud.com/docs/api/reference#connect. One of the parameters than can be changed is the response_type. The additional parameters are display, state and scope which are listed out in the above link