请求流时的Sonos身份验证

Question

事先道歉，这个问题可能过于模糊，无法被接纳到好的StackOverflow问题的大炮中。但它确实反映了我对该领域的当前状态。

Sonos使第三方服务能够为Sonos用户提供音乐服务。据我所知，Sonos提供的文档非常全面。

但是，我们有服务提供商A为用户提供以下服务的方案：

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

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

然而，我正在努力在Sonos的背景下对此进行推理。

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

Container1

• 第1项（＆＃39;播客＆＃39;属于服务A）
• item2（歌曲，属于服务B）

我在服务A和服务B注册，服务A和服务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将向服务B发送服务A的凭证，因此流将失败（因为它为什么会知道服务A与服务B具有预先存在的关系，服务A用户消费来自服务B的内容，如果所述用户已经拥有服务B的帐户。）

所以没有办法在Sonos的背景下实现我想做的事情，或者我在这里从根本上误解了什么？

Answer 1

这是一个非常好的问题。

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

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

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