SoundCloud API认证规则更新后自定义播放器的修复方案咨询

解决方案 #

首先明确前提：SoundCloud当前的client_credentials授权流程不支持纯前端实现，你无法仅修改前端JS代码完成适配，必须新增后端代理层处理认证逻辑，避免密钥泄露。

第一步：前置准备

你需要先在SoundCloud开发者后台确认应用的client_id和client_secret，这两个值是获取访问凭证的必要参数，禁止直接放在前端代码中。

第二步：后端代理逻辑实现

所有和SoundCloud API的交互都通过你的后端服务转发，后端需要实现两个核心逻辑：

• 定期获取并缓存access_token
  调用SoundCloud凭证接口https://api.soundcloud.com/oauth2/token，发送POST请求，携带以下参数：

  参数	值
  grant_type	client_credentials
  client_id	你的应用client_id
  client_secret	你的应用client_secret

  接口返回的access_token有效期通常为1小时，你可以在后端缓存该值，快过期时重新请求新凭证即可，无需每次调用API都重新获取。
• 实现API代理接口
  提供前端调用的代理接口，收到前端请求后，在转发到SoundCloud API时自动添加请求头：Authorization: OAuth 你缓存的access_token，再将SoundCloud返回的结果原样返回给前端。

第三步：前端代码修改

你现有代码中的JSONP请求逻辑已经无法使用，因为JSONP不支持自定义请求头，需要改成普通AJAX请求，对应修改如下：

// 原scApiUrl函数修改为指向你的后端代理接口
scApiUrl = function(scResourceUrl) {
  // 此处为你的后端代理接口地址，将SoundCloud资源地址编码后作为参数传递
  return '/soundcloud-proxy?resource_url=' + encodeURIComponent(scResourceUrl);
}

// 原JSONP请求替换为普通fetch请求示例
fetch(scApiUrl(待解析的SoundCloud音轨链接))
  .then(res => res.json())
  .then(scResourceData => {
    // 后续的资源解析、播放逻辑和原有代码保持一致即可
  })

注意事项

• 你之前考虑的新增callback URL的方案无法解决问题，当前API废弃的是URL参数传递client_id的认证方式，和回调地址无关。
• 必须保证client_secret和access_token不会泄露到前端，否则会导致你的应用权限被滥用。
• 后端代理时需要同步处理SoundCloud API的跨域、限流问题，避免前端请求失败。

内容的提问来源于stack exchange，提问作者Osu