-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Directly provide the dealer token #7
Comments
That's awesome! When I have time, I'll go ahead and add support for it. If you want to fork it and add support, go on ahead. It shouldn't be too difficult, except for some bits with audio analysis – however since you are generating a token you can just generate one with audio analysis included. |
The best approach for this would be to create another extension of SpotifySocket that works with access tokens instead of a cookie. Most stuff is already coded to be unaware of how the token is generated, so it should be easy to do. The CoordinatedSpotifySocket is what handles cookies and converting them to tokens. |
lol I had the same reaction:) it seems that spotify are finally willing to enlarge the world of possibilites for the devs |
@EricRabil Just tried to use your library with the web token but it seems that this token doesnt grant access to 'https://guc-spclient.spotify.com/connect-state/v1/devices/hobs_${device.device_id}' cause this endpoint respond with a 403. how important is this endpoint ? |
Fairly sure that bit is required for the current cluster (shared state) observation procedure. However, if the playback SDK supports receiving state updates, I’m happy to reverse it and switch to that protocol instead.
From: Le Couteur Paul ***@***.***>
Reply-To: EricRabil/sactivity ***@***.***>
Date: Sunday, June 6, 2021 at 3:57 PM
To: EricRabil/sactivity ***@***.***>
Cc: Eric Rabil ***@***.***>, Mention ***@***.***>
Subject: Re: [EricRabil/sactivity] Directly provide the dealer token (#7)
@EricRabil<https://github.com/EricRabil> Just tried to use your library with the web token but it seems that this token doesnt grant access to 'https://guc-spclient.spotify.com/connect-state/v1/devices/hobs_${device.device_id}<https://guc-spclient.spotify.com/connect-state/v1/devices/hobs_$%7Bdevice.device_id%7D>' cause this endpoint respond with a 403. how important is this endpoint ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#7 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB5N7BOIZ65NIU4BBDZET73TRPHJTANCNFSM46DIC2QA>.
|
@EricRabil I am not sure if the web sdk token is able to observe the shared state, the documentation keeps using the words like "local playback has changed" so unfortunatly maybe it's intentional that it's not possible to use this token for that purpose. |
I was reading https://developer.spotify.com/documentation/web-playback-sdk/quick-start/# and it seems that you can use the "Web Playback SDK access token" as a token to connect to the spotify websocket.
I just run their example and indeed, you can ask for a token with the scopes ["streaming", "user-read-email", "user-read-private"] and use it directly to connect to for instance : "wss://gew-dealer.spotify.com/?access_token=MY_TOKEN"
This potentially eliminate the need to use a cookie and enable the possibility to request the token using your favorite OAuth flow. My sugggestion is that the Sactivity class could directly use a token string instead of a cookie string:)
Cheers,
Paul.
The text was updated successfully, but these errors were encountered: