mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1179] Error 403 #545
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#545
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @xhpohanka on GitHub (Jun 20, 2023).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1179
Hello,
suddenly my librespot instance on libreelec stopped playing any songs.
I think it is similar to #972 if it is not the same, but I have not found any way how to fix it yet...
@xhpohanka commented on GitHub (Jun 22, 2023):
It seems that libreelec jumped directly to development branch, version
0.4.2works fine...@JasonLG1979 commented on GitHub (Jun 23, 2023):
This is the main blocker for me to switch to dev in Raspotify if/when this PR is merged I plan on poking around the network code and seeing if I can figure out a fix. I might checkout librespot java and see what works for them and attempt to port it over? Up until this point though my knowledge and contributions have primarily been limited to the audio side of the code base. The author of most of the network stack isn't active in the project anymore so I could use whatever help anyone can offer.
In the meantime the workaround is to disable zeroconf discovery and use your Spotify credentials to log librespot in manually.
@herrernst commented on GitHub (Jun 27, 2023):
Happens to me (in Austria) also since yesterday, never has happened before. Using current
devbranch.@JasonLG1979 commented on GitHub (Jun 27, 2023):
I'm in the US, and discovery hasn't worked for me in dev for a year or more. I don't think the network bits in dev are complete? I think they're kinda in a transitional place between APIs? That was @roderickvd's baby but I'm not sure where he left off?
@JasonLG1979 commented on GitHub (Jun 27, 2023):
If I had to guess it may be that the 403 is because we're still using
http://apresolve.spotify.comand those ap's are returning 403's because they are not local to us as far as Spotify is concerned but they may be local so some people including @roderickvd because when he made the changes that broke discovery for all of us it still worked for him so he thought it was Ok.I don't think that the dealer API has been implemented yet? That may fix discovery for everyone, idk though? All of that are just guesses. I'm not very familiar at all with the Spotify API's or the networking bits of librespot. My focus is generally on the audio side of things.
@roderickvd commented on GitHub (Jun 28, 2023):
Sure you can look at that.
librespot-javais also pretty dormant, although I think last few weeks it has also seen a couple of issues and who knows commits on network problems. Seems like Spotify is changing things on their side.Last time I reworked the network code, I took
librespot-javaas basis and updated that based on the latest official Spotify clients at that time, proxying the traffic and mimicking the requests. For example, thisdevsends more extensive query strings (with client ID for example) thanlibrespot-javadoes. Maybe stripping it down will fix things, I don't know, I'd actually recommend following the latest clients again and updating any code necessary.Except for the dealer (websockets-based messaging) that is not in, it should be fully functional and was ready for release pending wider testing.
I cannot think of any reason why the access point resolver should influence zeroconf discovery.
apresolve.spotify.comis what the official clients use for geographically load balanced DNS lookups.Also the dealer holds no relationship with zeroconf discovery. The dealer, simply put, replaces the current
spircmessaging interface between the Spotify server and client. Which also has no relationship with zeroconf discovery.Concerning zeroconf you may want to go through the commit log in
librespot-discovery. I remember I did update some code there related to how the service is advertised. Not sure anymore.I understand this may not seem helpful, though hopefully it will rule out some things or help focus any debugging efforts. Because that's what should happen really.
@JasonLG1979 commented on GitHub (Jun 28, 2023):
I tried that no dice.
That was just a guess. Basically me pulling stuff out of my butt,lol!!!
I guess I get to bisect,lol!!! Because discovery in stable works perfectly fine for me.
No, it is very helpful. It narrows my target. Thanks.
After I figure this out my next step as far as discovery is to replace
with-dns-sdwith an option to use avahi on Linux via it's DBus interface. @Johannesd3 already did most of the work here: https://github.com/Johannesd3/dnssd-rs/blob/master/src/avahi.rs. But it doesn't really make much sense to work on that until the current issue is fixed.@herrernst commented on GitHub (Jun 28, 2023):
When I start librespot with
--username USERNAMEand enter my password, it works FWIW@JasonLG1979 commented on GitHub (Jun 28, 2023):
Same. That's the only way it dev has worked for me in a long time.
@roderickvd commented on GitHub (Jun 29, 2023):
To add to tracing down the issue, maybe
devis sending a client or device ID as part of the discovery request that is not correct. Or the HTTP worker / spclient is sending a header that does not correspond to the actual client or device ID.@JasonLG1979 commented on GitHub (Jun 29, 2023):
I'll step though the discovery changes from stable (which works perfectly fine) to the current state of dev and see what broke what.
@kingosticks commented on GitHub (Jun 29, 2023):
I just gave it a try and discovery is still working for me using dev:
@roderickvd commented on GitHub (Jun 30, 2023):
Also from Europe right?
So weird.
@kingosticks commented on GitHub (Jun 30, 2023):
Yep, I'm in the UK. I can share the IP that my access point resolves to and someone who's having problems can try to hardcode that, to see if it makes any difference ?
@kingosticks commented on GitHub (Jun 30, 2023):
And one thing which I'm not 100% clear on here (sorry if I missed it), for those having discovery problems, can you confirm that librespot-java's discovery does actually work instead? I can't see what would be different at this fundamental level, all we've done up to this point is a session login (working) and then ask for a token (broken). It's only later on that things start to diverge between the two implementations.
@herrernst commented on GitHub (Jun 30, 2023):
By the way, I also tried from another Internet connection in Austria, and there it works! And if I've read correctly, it did use the same access points. Will investigate further ...
@kingosticks commented on GitHub (Jun 30, 2023):
If possible can you double check that the same access point hostname definitely resolves to the same IP in both working and non-working cases? Presumably it was the same user account in both cases also?
@xhpohanka commented on GitHub (Jun 30, 2023):
I have no time now to look closer to the log, but it seems to me that librespot-java also ends with 403 here in Czechia...
@kingosticks commented on GitHub (Jun 30, 2023):
I wonder if https://github.com/librespot-org/librespot-java/issues/445#issuecomment-1006725762 holds the answer:
What type of devices are you using to connect to librespot with? When I tried it yesterday (working) I was running librespot on Linux and connecting from the Android app. I've just tried running librespot on Windows and connecting from the Windows app but now I see error 403 from hm://keymaster/token/authenticated. Annoyingly, for some reason the Android app can't see librespot running on my Windows box, which I really wanted to test. Maybe someone else will have more luck there.
The way login works on their Windows client has definitely changed from what I remember. You now have to do an OAuth login through your web browser which provides their app with an "Authorization Code" which it then exchanges for an access token. I am guessing it then uses that access token to create a Mercury session (usingauth type
AUTHENTICATION_SPOTIFY_TOKEN??) from which to obtain stored credentials, those stored creds are then used with login5.spotify.com/v3/login - which seems to provide another access token that's used for everything interesting via spclient.wg.spotify.com. I suspect this client isn't using keymaster anymore, maybe it's not using Mercury/hermes at all. Sadly I don't have anything setup to capture the hermes traffic (is there anything that still works for this?).So maybe there is something different with the credentials blob passed via discovery, depending on what client you use? And some blobs don't have permission (scope) to access keymaster. Can anyone else help test that theory?
@roderickvd commented on GitHub (Jun 30, 2023):
You may be onto something here. From what I remember, the Windows client indeed uses a different keymaster ID. In dev I made changes to better mimicking that actual behavior and do the “right thing” per platform instead of using the same ID everywhere. And/or I think I am also sending the actual client ID gotten from discovery instead of a hardcoded one.
Finally I rarely used Spotify on Windows so probably haven’t properly tested it either.
@JasonLG1979 commented on GitHub (Jun 30, 2023):
In my case librespot runs on Linux and so do the players either via the web player in a browser or the Linux desktop client, which is AFAIK basically an electron app so basically the web client. I will check again but I don't remember having any luck from my Android phone either.
I also made sure to be signed in directly to Spotify and not through Facebook or Google if that makes a difference.
@JasonLG1979 commented on GitHub (Jun 30, 2023):
Ok just checked and it works fine from my phone.
@kingosticks commented on GitHub (Jun 30, 2023):
I've had success getting the bearer access token using login5 instead of keymaster with https://github.com/kingosticks/librespot/tree/auth-token-from-login5. This is currently what the official Windows client does and is (something like) what we should move towards anyway. I'm not 100% sure if I have broken anything else with this hack, I was very surprised it just worked. I think this will also unblock https://github.com/librespot-org/librespot/pull/1098 which is nice.
@JasonLG1979 commented on GitHub (Jul 1, 2023):
@kingosticks That works for me as expected so far with the Linux desktop client. I think you're on the right track and big thanks for figuring this out.
@SuisChan commented on GitHub (Jul 1, 2023):
Was it a problem to get a bearer token? For some reason I thought it just wasn't implemented
@kingosticks commented on GitHub (Jul 1, 2023):
No problem and yes that's correct. I could have phrased that better. What I meant to say is I had success fixing playback by implementing login5 and obtaining an access token that way. Just as you had suggested doing in a previous issue somewhere - thanks for the tip. The alternative method using keymaster now seems to be dead in some cases.
@xhpohanka commented on GitHub (Jul 1, 2023):
I can confirm that @kingosticks branch is working for me on linux with linux and android clients too...
@herrernst commented on GitHub (Jul 2, 2023):
I can confirm that current dev works only when initiated from iOS client, but not when initiated from macOS desktop client. (So it has most certainly nothing to do with my internet connection.) I can also confirm that initiation from desktop macOS app now works with the branch from @kingosticks . Unfortunately, with this branch, playback from iOS client results in an error:
@kingosticks commented on GitHub (Jul 3, 2023):
Can you get a log with more debug. I don't have Apple devices.
I wonder if this is because
spclient.requestis now always sending a client-token header along with the auth token it got from login5. Perhaps some requests don't like that.@Gerrelt commented on GitHub (Jul 3, 2023):
I had the same 403 problem, and it was also solved by using @kingosticks branch.
I now have librespot running on piCore (14.0) and Raspbian (11 Bullseye), connecting to it with the windows and android spotify app, all working fine. Thanks kingosticks!
@herrernst commented on GitHub (Jul 3, 2023):
Thank you @kingosticks. Here is a more detailed log when using the iOS app:
@xhpohanka commented on GitHub (Jul 27, 2023):
Hi - will the @kingosticks's PR be merged? I don't know if the solution is optimal but for me it works :)
@roderickvd commented on GitHub (Jul 27, 2023):
If he can make it a PR? Currently it’s in one of his branches but not yet a PR here.
@kingosticks commented on GitHub (Jul 27, 2023):
I can't remember what state it is in. I'll take a look when I get time
@eldar commented on GitHub (Sep 3, 2023):
I can confirm that @kingosticks branch fixes it for me. Any chance this get merged?
@kingosticks commented on GitHub (Sep 4, 2023):
I'm away for the next week without a computer. Anyone who has the time is welcome to take the code and submit a PR. I can't remember what state I left it in.
@Gerrelt commented on GitHub (Nov 13, 2023):
I've created a pull request with the changes of @kingosticks , I am not an experienced github user, so I hope I did it right..
Thank you @kingosticks for providing this solution.
Here's the pull request:
https://github.com/librespot-org/librespot/pull/1220
@herrernst commented on GitHub (Nov 13, 2023):
Have you tested this change with an iOS client? Because it then broke for me on iPhone
@Gerrelt commented on GitHub (Nov 13, 2023):
No, but I can test it with an iPhone, I'll be back.
@herrernst commented on GitHub (Nov 13, 2023):
Please test the case when iPhone makes the first connection. So after (re)starting librespot.
@Gerrelt commented on GitHub (Nov 13, 2023):
I've rebooted the Raspberry Pi, connected to the spotify connect device in the iPhone spotify app, and it worked.
We played around a bit, skipped to the middle of the song, skipped to the next song, let it go to the next song automatically, and it all worked fine.
@herrernst commented on GitHub (Nov 13, 2023):
Okay, great. I only had a problem when the iOS client did the authentication, but that was some weeks or even months ago (I am currently not a Premium subscriber anymore, so I can't test). But if I remember correctly, when using with @kingosticks' change iOS client couldn't authenticate:
If it works now, that would be great.
@roderickvd commented on GitHub (Nov 14, 2023):
Let's continue this conversation at #1220