search

i8beef / node-red-contrib-castv2

MIT License
22 stars 14 forks source link

How test Spotify ? #59

Closed m4dm4rtig4n closed 3 years ago

m4dm4rtig4n commented 3 years ago

Hi,

Where to find this config to test spotify ?

image

i8beef commented 3 years ago

That is all placeholder until someone with a Spotify account comes along to finish the implementation. You cannot currently make use of it.

m4dm4rtig4n commented 3 years ago

I have premium account, what are you missing for the setup?

i8beef commented 3 years ago

Its just not implemented in the code. Spotify does not use a standard cast protocol implementation, they invented their own strategy. If you've ever wondered why their cast support is janky... well thats why....

If I understand correctly, the cast protocol would only be used to launch their app, and then past that all interactions are meant to be done against their API directly specifying your "device id" for queue commands, and then their API talks to their app running on the cast device, bypassing the entire cast protocol.

Frankly, I should rip out the custom Spotify stuff because there's a pretty nasty crash opportunity in there due to some code I didn't comment out if you happened to get it to attempt to auth...

What would essentially need to be done is:

  1. Choose a Spotify library to facilitate the API calls. Specifically, probably spotify-web-api-node
  2. Get an auth stream working that DOESN'T require exposing extra endpoints for auth callbacks, etc. Normally I would say this means a 'client credentials' flow... but Spotify limits what you can do with that flow (source). Note I mention this because if you look at node-red-contrib-spotify, they do some stuff that is way outside the scope here to facilitate the full auth flows that I wouldn't allow here.
  3. Handle proper token storage and refresh, possibly in hidden state properties of the config node and a refresh check before all calls.
  4. Implement the SpotifyController methods to forward calls to this API instead of the cast protocol.

Point 2 is kind of where I left it because I (a) didn't have an account to try with and (b) I thought the client credentials flow wouldn't work, and the other auth mechanisms are no-gos. If that is the case, then this is dead and I just need to remove the code.

But the skeleton is there for someone else to attempt.

i8beef commented 3 years ago

Note also, it might be possible to do something like LAUNCH the app using this node, waiting a second for it to start and register with Spotify's API, and then using the node-red-contrib-spotify node to get the device ID and send control commands. Actually, if that worked, I almost like that BETTER because it allows this node to stay "pure" instead of having to implement one off "because we could" implementations for companies like Spotify that refuse to do things the normal way... worth experimenting with at least.

m4dm4rtig4n commented 3 years ago 
Note also, it might be possible to do something like LAUNCH the app using this node, waiting a second for it to start and register with Spotify's API, and then using the node-red-contrib-spotify node to get the device ID and send control commands. Actually, if that worked, I almost like that BETTER because it allows this node to stay "pure" instead of having to implement one off "because we could" implementations for companies like Spotify that refuse to do things the normal way... worth experimenting with at least.

This mode could suit me personally, I do not currently have the skills and especially the time to work on the integration part of Spotify :/

i8beef commented 3 years ago

Yeah, its essentially the auth requirements that limit this. I think Im just going to back off Spotify support altogether as I am not keen on adding app specific OAuth support for a generic cast solution. If Spotify allowed client credential flows to access user resources like devices and playlists, etc., it could be done close to how I was envisioning support before... but because they require a full auth code handshake for those operations, my hands are a little tied.

Frankly I'd almost say this functionality would be better in the node-red-contrib-spotify node, but even that's a little hard to stomach, making their node cast aware... but that's kind of where Spotify has put us here... it looks like in order to even start the Spotify app, you have to follow it up by setting the current auth token credentials in a custom cast directive to tell the Spotify cast app who it should be running as, so I'm not even sure just "launching Spotify" from this node would be sufficient because it has an INHERENT requirement for auth token access. Which is why I think making it a function of the spotify specific node, or some hybrid of both our nodes in a NEW one, makes the most sense. They essentially built their solution around "Spotify cast can only be started from the Spotify app".

Sorry man, I was trying to make an exception for Spotify, but they really don't make it easy.

i8beef commented 3 years ago

Closing as explicit support for Spotify has been removed.