Soundcloud Oauth 实施：为什么是哈希参数？

Question

关于https://github.com/sinatra/sinatra/issues/596，我错误地诊断为sinatra bug。

我遇到以下问题：我正在使用 Soundcloud OAuth 工作流程在我的项目中实现单点登录。为此，我正在使用“soundcloud” gem。因此，在被重定向到 soundcloud 的登录/授权表单并按下“连接”后，我被重定向回我指定为重定向 url 的应用程序中的 URL……但是一些哈希参数落后了！因此，假设我没有被重定向到“http://myapp.com/connect?code=123”，而是被重定向到“http://myapp.com/connect?code=123#access_token=qwerty” ”。由于散列参数不是 HTTP 协议的一部分，它确实对服务器有次要影响，但在客户端上，bleepin 散列参数并没有消失！基本上，在我的重定向端点上，我正在获取 soundcloud 提供的代码，ping Soundcloud 的令牌交换以获得新的访问令牌，将其存储并重定向到我的主页“/”。但是浏览器不会清除重定向时的哈希参数，这意味着我被重定向到“http://myapp.com/#access_token=qwerty”。这很糟糕。是否有解决此问题的方法，或者这是 soundcloud“错误”？ （不完全是一个错误，因为它不会破坏任何东西，在那里有那些散列参数简直丑陋）。

Answer 1

[在你链接的那个帖子中回答了同样的事情，但会在这里尝试总结一下]

我能想到的一个原因是确保 JS 交叉兼容 API。即在使用JS对用户进行认证时，读取认证url参数结果的唯一方法是——通过解析URL中#后面的属性。这是我所能推断的设计。

是的，有一个解决方法：

实际上，API 服务器还有更多尚未在 Ruby 驱动程序中直接实现的功能。 client.authorize_url 调用的结果属于这种类型：

"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)

response_type 参数也可以采用其他值，但不幸的是，这不是 Ruby API 包装器中现成的功能。可能的值是：

• response_type=code 嵌入了code，以后可用于生成用户的access_token。这可以通过运行 API 参考文档中提到的 client.exchange_code(:code => params[:code]) 来完成。
• response_type=token 嵌入了 access_token 并避免了 code 参数。但是，与code 参数不同，access_token 不是查询参数，而是以# 为前缀，因此，JS 是获取此值的唯一方法。

您可以在这里验证：http://developers.soundcloud.com/docs/api/reference#connect。可以更改的参数之一是response_type。附加参数为display、state 和scope，在上面的链接中列出