Error 403 #1179
Comments
|
It seems that libreelec jumped directly to development branch, version |
|
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. |
|
Happens to me (in Austria) also since yesterday, never has happened before. Using current |
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? |
|
If I had to guess it may be that the 403 is because we're still using 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. |
Sure you can look at that. Last time I reworked the network code, I took
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.
Also the dealer holds no relationship with zeroconf discovery. The dealer, simply put, replaces the current Concerning zeroconf you may want to go through the commit log in 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. |
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 |
|
When I start librespot with |
|
Same. That's the only way it dev has worked for me in a long time. |
|
To add to tracing down the issue, maybe |
I'll step though the discovery changes from stable (which works perfectly fine) to the current state of dev and see what broke what. |
|
I just gave it a try and discovery is still working for me using dev: |
|
Also from Europe right? |
|
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 ? |
|
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. |
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 ... |
|
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? |
|
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... |
|
I wonder if librespot-org/librespot-java#445 (comment) 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 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? |
|
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. |
|
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. |
|
Ok just checked and it works fine from my phone. |
|
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 #1098 which is nice. |
|
@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. |
Was it a problem to get a bearer token? For some reason I thought it just wasn't implemented |
|
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. |
|
I can confirm that @kingosticks branch is working for me on linux with linux and android clients too... |
|
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: |
|
Can you get a log with more debug. I don't have Apple devices. I wonder if this is because |
|
I had the same 403 problem, and it was also solved by using @kingosticks branch. |
|
Thank you @kingosticks. Here is a more detailed log when using the iOS app: |
|
Hi - will the @kingosticks's PR be merged? I don't know if the solution is optimal but for me it works :) |
|
If he can make it a PR? Currently it’s in one of his branches but not yet a PR here. |
|
I can't remember what state it is in. I'll take a look when I get time |
|
I can confirm that @kingosticks branch fixes it for me. Any chance this get merged? |
|
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. |
… of keymaster (Fixes librespot-org#1179)
|
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.. Here's the pull request: |
|
Have you tested this change with an iOS client? Because it then broke for me on iPhone |
|
No, but I can test it with an iPhone, I'll be back. |
|
Please test the case when iPhone makes the first connection. So after (re)starting librespot. |
|
I've rebooted the Raspberry Pi, connected to the spotify connect device in the iPhone spotify app, and it worked. |
|
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. |
|
Let's continue this conversation at #1220 |
… of keymaster (Fixes librespot-org#1179)
… of keymaster (Fixes librespot-org#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...
The text was updated successfully, but these errors were encountered: