0

提前道歉，这个问题可能太模糊，无法被纳入良好的 StackOverflow 问题的大炮中。然而，它确实反映了我对该领域知识的当前状态。

Sonos 为第 3 方服务提供了向 Sonos 用户提供音乐服务访问权限的能力。这个我理解，Sonos提供的文档很全面。

但是，我们有Service Provider A为用户提供以下服务的场景：

  1. 访问流式广播（A 有权并可以提供流式广播）
  2. 访问点播/追赶内容（A 有权并可以提供流）
  3. 能够创建在 1 和 2 中播放的音乐的播放列表（A 没有权限，而是通过用户拥有帐户的一个或多个第 3 方音乐服务提供流）。

这在 A 自己的应用程序的上下文中非常有效 - 其中包括与 3rd 方音乐服务的集成，这些服务为 3 以下的内容提供流（即，如果您是 A 的用户，那么您可以创建播放列表，如果您愿意要实际播放播放列表中的曲目，则需要一个拥有该特定曲目权利的服务提供商的帐户）。

但是，我很难在 Sonos 的背景下对此进行推理。

如果，作为 A 的用户，我有以下容器：

容器1

  • item1（属于服务 A 的“播客”）
  • item2（歌曲，属于Service B）

我注册了服务 A 和服务 B，并且服务 A 和服务 B 在 Sonos 上都可以单独使用，并且都使用 DeviceLink 进行身份验证（在本示例中假设服务 B 是 Spotify）。

如果用户请求容器，将 item1 添加到他们的队列中，然后按下播放，播放器将从服务 A 请求流式处理 uri，服务 A 将以以下格式返回它：

http://service-a.uri/some-file

然后，播放器将对这个 uri 执行 GET 请求，并且项目将开始播放。

但是，如果用户将 item2 添加到他们的队列中然后按下播放，则服务 A 将返回属于服务 B 的流式 uri，如下所示：

http://service-b.uri/some-file

在这种情况下，如何处理身份验证？

用户通过以下方式进行身份验证：

在服务 A 内：

  • 服务 A
  • 通过服务 B 的 API 到服务 B。

在 Sonos 内：

  • 服务 A
  • 至服务 B

但是，Sonos 会将服务 A 的凭据发送到服务 B，因此流将失败（因为它为什么会知道服务 A 与服务 B 具有预先存在的关系，服务 A 用户使用服务 B 的内容，如果说用户已经拥有服务 B 的帐户）。

所以没有办法在Sonos的背景下实现我想要做的事情，还是我从根本上误解了这里的一些东西？

4

1 回答 1

1

这是一个非常好的问题。

对于流式 Sonos 请求带有 getMediaUri 请求的 uri。然后使用此 uri 流式传输内容。如果作为此请求的结果返回的 uri 是可流式传输的，那么应该没有问题。可以包含应该与 uri 请求一起发送的标头，如果需要一些额外的身份验证，也可以使用这些标头。（例如将身份验证令牌传递给服务 B）。但是，这里的要求是服务 A 将拥有正确将此信息传递给 Sonos 所需的一切，以便 Sonos 可以将其包含在对服务 B 的请求中。

出于安全原因，Sonos 目前没有办法将服务 B 的身份验证令牌或信息传递给服务 A；Sonos 播放器也无法知道它请求的由服务 A 提供的 URL 实际上是为服务 B 提供的。播放器也无法通知服务 A 用户也安装了服务 B .

这是我们已经考虑过的事情，并将考虑在未来提供一种机制来支持这一点。

于 2015-10-11T17:25:47.347 回答