Authentication failures #1308
Comments
|
It appears to be for some users only. It's still working for me right now. So reproducing it (to debug it) might not be so simple (yet). |
|
The same code gives bad credentials error on my linux machine, but works everytime on Windows. Tried multiple accounts. |
|
Same problem on my Linux machine since today. Yesterday it was still working fine. Ubuntu 22.04. |
|
For the record, which version of librespot? 0.4? dev? Those downstream packages use 0.4 I presume. Please try them both. I remember I made some changes on it to dev. Re: @kingosticks would also not be the first time that something gets broken / changed on Spotify's end, only to have it restored the day or week after. Anyway, having it work on one platform and not the other is fishy. |
|
I tried |
|
0.5.0-dev is also affected on Arch kernel version 6.9.7. Immediately after posting this, I tried again, and it just worked? I'm not entirely sure what changed; my systemctl script hasn't changed, but after a number of auto-restarts, it came back authenticated? Very strange! |
|
Same issue here |
|
Same Here |
|
FWIW, the original bug report was made against latest dev on a Debian system that previously was working fine, with no new packages installed since breaking. (I built from git initially to see if it was fixed upstream.) Feel free to reach out if you need any assistance to debug the issue, I'd be happy to help. |
|
Given it's working on Windows, what if you change this line: librespot/core/src/connection/mod.rs Line 91 in 299b7de To pretend that it's always Windows? You may need to do the same here: librespot/core/src/connection/handshake.rs Line 113 in 299b7de Then in It's the only thing I can now think of why it would work on Windows but not on Linux. |
|
Same issue here. |
|
@roderickvd Quickly checked the solution, not working, sadly. System: NixOS 24.05.20240727.8c50662 (Uakari) x86_64 |
|
Reporters, please add the access point / servers you are connecting to:
I'm reading that the issue is on Windows also, so let's try to triangulate what's happening. |
|
Getting this in New Zealand, using librespot-java v1.6.3 on Windows 10. Using USER_PASS auth.
|
|
Server: Ping Result: |
|
From a raspberry pi 4 running LibreELEC: |
Probably it happens once your token expires |
|
Using Full logspotifyd | 2024-07-30 08:33:28,288 INFO ApResolver:99 - Loaded aps into pool: {accesspoint=[ap-gew1.spotify.com:4070, ap-gew1.spotify.com:443, ap-gew1.spotify.com:80, ap-guc3.spotify.com:4070, ap-gue1.spotify.com:443, ap-gae2.spotify.com:80], dealer=[gew1-dealer2.spotify.com:443, guc3-dealer2.spotify.com:443, gue1-dealer2.spotify.com:443, gae2-dealer2.spotify.com:443], spclient=[gew1-spclient.spotify.com:443, guc3-spclient.spotify.com:443, gue1-spclient.spotify.com:443, gae2-spclient.spotify.com:443]}
spotifyd | 2024-07-30 08:33:28,441 INFO Session:140 - Created new session! {deviceId: , ap: ap-gue1.spotify.com:443, proxy: false}
spotifyd | 2024-07-30 08:33:29,092 INFO Session:334 - Connected successfully!
spotifyd | 2024-07-30 08:33:29,421 ERROR Log4JUncaughtExceptionHandler:31 - [main]
spotifyd | xyz.gianlu.librespot.core.Session$SpotifyAuthenticationException: BadCredentials
spotifyd | at xyz.gianlu.librespot.core.Session.authenticatePartial(Session.java:453) ~[librespot:1.6.3]
spotifyd | at xyz.gianlu.librespot.core.Session.authenticate(Session.java:342) ~[librespot:1.6.3]
spotifyd | at xyz.gianlu.librespot.core.Session.access$600(Session.java:77) ~[librespot:1.6.3]
spotifyd | at xyz.gianlu.librespot.core.Session$Builder.create(Session.java:1057) ~[librespot:1.6.3]
spotifyd | at xyz.gianlu.librespot.player.Main.main(Main.java:80) ~[librespot:1.6.3]
spotifyd | 2024-07-30 08:34:30,706 INFO ApResolver:99 - Loaded aps into pool: {accesspoint=[ap-gew1.spotify.com:4070, ap-gew1.spotify.com:443, ap-gew1.spotify.com:80, ap-guc3.spotify.com:4070, ap-gue1.spotify.com:443, ap-gew4.spotify.com:80], dealer=[gew1-dealer2.spotify.com:443, guc3-dealer2.spotify.com:443, gue1-dealer2.spotify.com:443, gew4-dealer2.spotify.com:443], spclient=[gew1-spclient.spotify.com:443, guc3-spclient.spotify.com:443, gue1-spclient.spotify.com:443, gew4-spclient.spotify.com:443]}
spotifyd | 2024-07-30 08:34:30,759 INFO Session:140 - Created new session! {deviceId: , ap: ap-gew1.spotify.com:443, proxy: false}
spotifyd | 2024-07-30 08:34:31,235 INFO Session:334 - Connected successfully!
spotifyd | 2024-07-30 08:34:31,429 ERROR Log4JUncaughtExceptionHandler:31 - [main]
spotifyd | xyz.gianlu.librespot.core.Session$SpotifyAuthenticationException: BadCredentials
spotifyd | at xyz.gianlu.librespot.core.Session.authenticatePartial(Session.java:453) ~[librespot:1.6.3]
spotifyd | at xyz.gianlu.librespot.core.Session.authenticate(Session.java:342) ~[librespot:1.6.3]
spotifyd | at xyz.gianlu.librespot.core.Session.access$600(Session.java:77) ~[librespot:1.6.3]
spotifyd | at xyz.gianlu.librespot.core.Session$Builder.create(Session.java:1057) ~[librespot:1.6.3]
spotifyd | at xyz.gianlu.librespot.player.Main.main(Main.java:80) ~[librespot:1.6.3]
|
i am affected too, since
UPDATE:
|
|
Unfortunately changing the OS in the match clauses as suggested did nothing. |
|
Same here in São Paulo, Brazil, stopped working yesterday afternoon. 6.10.2 kernel on Gentoo. |
|
Do we have a way to block or force misbehaving APs? Given these logs, at least the following fail: I tried the naive approach of pointing them to 127.0.0.1 in my /etc/hosts, but that triggers a connection error. Pointing them to another ap's IP also does not seem to do anything to avoid it. |
|
Is it confirmed that other APs continue to work well? It's not the first time that an AP starts misbehaving, but I don't remember this many. You could try pointing librespot/core/src/apresolve.rs Line 109 in 299b7de If you want to filter APs then you could do it in the same file, probably here: librespot/core/src/apresolve.rs Line 64 in 299b7de But filtering that many could result in an empty set... don't you only get like three or something? Edit: misbehaving APs usually get fixed, sometimes in a few days, sometimes weeks. Not sure if this is a transitive failure on Spotify's end, or something that's really changing. That's why it would be good if someone had an old HW device with Connect to test, not something with recent firmware... to see if they're really phasing out this interface. |
Note that you have to disable zeroconf |
|
Just to be clear, you can generate credentials.json via zeroconf using normal librespot as is: You can then connect to that librespot instance from an official Spotify client, doing so will generate credentials.json in SOME_DIRECTORY which you can move elsewhere as required. |
Strange, I did NOT use -O, as discovery was a feature I needed for this configuration, and it still worked fine. For what reason does discovery need to be disabled to use the credentials.json? |
|
Maybe one of the developers can weigh in here, but for Spotify Connect, where via API or the app on another network you can control librespot, it needs to authenticate to the Spotify web API. Zeroconf fetches those credentials from the spotify app running on another device, so you don't need cached credentials. For me it wouldn't use the cached credentials at all unless I disabled zeroconf. Note that I do not have the spotify app running on the same network as librespot and had to generate the cached credentials using the oauth2 flow from the fork posted earlier in this thread. |
|
If cached creds are present, they'll be used unless: a username and password is also specified, or just a username is specified and it is different to what's in the cached credentials. Using cached credentials and having Zeroconf enabled are orthogonal. |
|
Anyone know how to pass the I'm already using the params field: https://github.com/badaix/snapcast/blob/develop/doc/configuration.md#available-parameters But I'm not sure how to append Update: On another note, I'm having trouble running snapcast with the latest version of alpine... Just get a segfault... badaix/snapcast#1275 |
I thought it was a good idea to find an opening for more collaboration before I starting shooting more detailed questions at them. This is what I just wrote them:
I'll keep you informed if and how they respond. |
|
Thanks for your effort, @roderickvd. Unfortunately I happen to know that they have an issue with the lack of reporting (see #626). It's my vague memory that this was addressed in the Java version, but never made it to the Rust build? I could be wrong though, my memory is failing me way too often :(. |
|
Yes, librespot-java figured it out partially and it hasn't been back ported yet. Could be a good start for someone who wants to contribute - not super hard to send a message from the player to the session when a play finished, so the session can report it back to Spotify. I remember that the librespot-java version didn't work under all circumstances, and doesn't have all fields figured out, so any clarification from Spotify would be welcome. This is one of the things I thought of when I wrote "amongst other things" to Spotify - I'm all for artist monetisation but don't know if payout is high on Spotify's agenda. I am happy to hear from you that apparently it is, so if they could help us scratch that itch... |
So you basically mean create the credentials.json (with, lets say this ) and past the file in /data/librespot, and then in the snapserver.conf in the stream for spotify use this:
? Thank you in advance! |
|
I only removed the -u and -p parameters and it worked again, although it gave a warning: |
|
Okay I'm able to get my cred json file but not login, might be newbie question but would love some help. . |
Login challenge (hashcash)? It has always been like that |
|
OK I have a working email/password implementation, again it was just the addition of the user-agent basically: |
|
@DarpNagarsheth Have you solved the issue, i am facing the same issue using zspotify. |
There is no support for that tool here. Thanks. |
and others
"ERROR librespot] Connection failed: Login failed with reason: Bad credentials"
Credentials are valid.
I assume Spotify has changed the login flow. This affects upstream projects using librespot also, looking at their buglists.
The text was updated successfully, but these errors were encountered: