mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1308] Authentication failures #596
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#596
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 @dspearson on GitHub (Jul 29, 2024).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1308
"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.
@kingosticks commented on GitHub (Jul 29, 2024):
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).
@azel1 commented on GitHub (Jul 29, 2024):
The same code gives bad credentials error on my linux machine, but works everytime on Windows. Tried multiple accounts.
@quantverse commented on GitHub (Jul 29, 2024):
Same problem on my Linux machine since today. Yesterday it was still working fine.
Ubuntu 22.04.
@roderickvd commented on GitHub (Jul 29, 2024):
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.
@eladyn commented on GitHub (Jul 29, 2024):
I tried
0.4.2,devand one of the proposedlogin5changes, but all of them are broken for me. (although reconsidering what currently seems to be broken, thelogin5thing should indeed not have much effect)@andrewCohn commented on GitHub (Jul 29, 2024):
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!
@Losses commented on GitHub (Jul 30, 2024):
Same issue here
@Geral3 commented on GitHub (Jul 30, 2024):
Same Here
@dspearson commented on GitHub (Jul 30, 2024):
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.
@roderickvd commented on GitHub (Jul 30, 2024):
Given it's working on Windows, what if you change this line:
github.com/librespot-org/librespot@299b7dec20/core/src/connection/mod.rs (L91)To pretend that it's always Windows?
You may need to do the same here:
github.com/librespot-org/librespot@299b7dec20/core/src/connection/handshake.rs (L113)Then in
devthere's a similar thing in the HTTP client, but when you're authenticating, that's not yet where you are in the code flow.It's the only thing I can now think of why it would work on Windows but not on Linux.
@IVIanuu commented on GitHub (Jul 30, 2024):
Same issue here.
@Losses commented on GitHub (Jul 30, 2024):
@roderickvd Quickly checked the solution, not working, sadly.
System: NixOS 24.05.20240727.8c50662 (Uakari) x86_64
@roderickvd commented on GitHub (Jul 30, 2024):
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.
Are officially supported devices from the past (like stereo receivers, old Sonos thingies, whatever) also having issues?
@ssamjh commented on GitHub (Jul 30, 2024):
Getting this in New Zealand, using librespot-java v1.6.3 on Windows 10.
Using USER_PASS auth.
2024-07-30 19:45:17,085 DEBUG TimeProvider:90 - Loaded time offset from NTP: 1115ms 2024-07-30 19:45:18,142 INFO ApResolver:99 - Loaded aps into pool: {accesspoint=[ap-gae2.spotify.com:4070, ap-gae2.spotify.com:443, ap-gae2.spotify.com:80, ap-guc3.spotify.com:4070, ap-gue1.spotify.com:443, ap-gew4.spotify.com:80], dealer=[gae2-dealer2.spotify.com:443, guc3-dealer2.spotify.com:443, gue1-dealer2.spotify.com:443, gew4-dealer2.spotify.com:443], spclient=[gae2-spclient.spotify.com:443, guc3-spclient.spotify.com:443, gue1-spclient.spotify.com:443, gew4-spclient.spotify.com:443]} 2024-07-30 19:45:18,359 INFO Session:140 - Created new session! {deviceId: <snip>, ap: ap-guc3.spotify.com:4070, proxy: false} 2024-07-30 19:45:19,194 INFO Session:334 - Connected successfully! 2024-07-30 19:45:19,647 ERROR Log4JUncaughtExceptionHandler:31 - [main] xyz.gianlu.librespot.core.Session$SpotifyAuthenticationException: BadCredentials at xyz.gianlu.librespot.core.Session.authenticatePartial(Session.java:453) ~[librespot-api-1.6.3.jar:1.6.3] at xyz.gianlu.librespot.core.Session.authenticate(Session.java:342) ~[librespot-api-1.6.3.jar:1.6.3] at xyz.gianlu.librespot.core.Session.access$600(Session.java:77) ~[librespot-api-1.6.3.jar:1.6.3] at xyz.gianlu.librespot.core.Session$Builder.create(Session.java:1057) ~[librespot-api-1.6.3.jar:1.6.3] at xyz.gianlu.librespot.api.Main.withPlayer(Main.java:53) ~[librespot-api-1.6.3.jar:1.6.3] at xyz.gianlu.librespot.api.Main.main(Main.java:45) ~[librespot-api-1.6.3.jar:1.6.3]@Losses commented on GitHub (Jul 30, 2024):
@roderickvd
Server:
Ping Result:
@noahhaon commented on GitHub (Jul 30, 2024):
From a raspberry pi 4 running LibreELEC:
@erkr commented on GitHub (Jul 30, 2024):
Probably it happens once your token expires
@rgon commented on GitHub (Jul 30, 2024):
Using
librespot-javaand USER_PASS authap:
ap-gue1.spotify.comPing result:
Full log
spotifyd | 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]@bitclick commented on GitHub (Jul 30, 2024):
i am affected too, since
2024-07-29T09:37:23Z(in germany)see attached logfile for connection attempts and servers (before and after the error started happening)
librespot-connection-attempts.log
UPDATE:
@dspearson commented on GitHub (Jul 30, 2024):
Unfortunately changing the OS in the match clauses as suggested did nothing.
@BGazotti commented on GitHub (Jul 30, 2024):
Same here in São Paulo, Brazil, stopped working yesterday afternoon. 6.10.2 kernel on Gentoo.
@rgon commented on GitHub (Jul 30, 2024):
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.
@roderickvd commented on GitHub (Jul 30, 2024):
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
apresolve.spotify.comto 127.0.0.1 as it will force a fallback mechanism:github.com/librespot-org/librespot@299b7dec20/core/src/apresolve.rs (L109)If you want to filter APs then you could do it in the same file, probably here:
github.com/librespot-org/librespot@299b7dec20/core/src/apresolve.rs (L64)But filtering that many could result in an empty set... don't you only get like three or something?
So that should also make it resort to a fallback. No guarantees the fallback AP will work, although in the past it did.
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.
@kingosticks commented on GitHub (Jul 30, 2024):
Yes, actually, I would have been using cached credentials (which don't expire). This session login failure is for the access point, it's not token based.
I've got a Windows 11 machine here today and no cached credentials. Both dev and master fail:
I wonder if the one reported working Windows env above was also using cached creds? @azel1 can you provide a working log?
@kingosticks commented on GitHub (Jul 30, 2024):
They are phasing out the car thing in December. When Spotify started phasing out libspotify (their old official native library) they intermitently repeatedly broke lots of things in the run-up to turning it off. The theory was that they had no idea how the old and new parts of their systems depended on each other.
Does spotify-analyze still work? How can we observe the AP login these days?
@SuisChan commented on GitHub (Jul 30, 2024):
Idk, but on Windows you can use x64dbg to find 'shn_keys' or/and read the client's transmitted data
@roderickvd commented on GitHub (Jul 30, 2024):
I think
spotify-analyzeneeds on overhaul to make it work again. Have not used it in ages and I remember it was broken two years ago.@roderickvd commented on GitHub (Jul 30, 2024):
Yeah, nice that tribal development scheme.
@microfx commented on GitHub (Jul 30, 2024):
so what's the workaround? Can I maybe switch to an app API key that authenticates my librespot? Librespot is crashing all the time due to this.
This happened even during playback / using librespot ... just crashed and then stopped being available
Connecting to AP "ap-gew4.spotify.com:4070"@roderickvd commented on GitHub (Jul 30, 2024):
That’s what we’re trying to find out. If you want to help, please read my posts to see what you can do to help nail it down.
Edit: as a kind reminder, I don’t use Spotify or even have an account anymore, so I’m here to give pointers and think along but it’s up to you guys.
@noahhaon commented on GitHub (Jul 30, 2024):
FWIW I tried this by modifying
/etc/hostsand saw it trigger the fallback and got the same result :(@SuisChan commented on GitHub (Jul 30, 2024):
Anyway, does the latest spotify version (win, mac etc) connect to port 4070 or not anymore? (last time I checked, the only thing the client was sending to the server was information about listening events). (I don't have access to the desktop right now, but it's easy to check with Wireshark)
@microfx commented on GitHub (Jul 30, 2024):
does this help?! I will test macOS desktop client now
@rgon commented on GitHub (Jul 30, 2024):
@bitclick
Can confirm local (without login) works(at least on master, librespot 0.0.0-dev
299b7de), so @microfx that's one possible workaround! Edit: if your use case can live without remote access, of course.@dspearson commented on GitHub (Jul 30, 2024):
Version 3.203.235
My suspicion is that this is the cause.
See: https://developer.spotify.com/documentation/commercial-hardware/implementation/changelog (assuming this is using the Spotify Connect API)
@roderickvd commented on GitHub (Jul 30, 2024):
Well there you seem to have it.
Naive question but how would this impact the login5 approach?
@kingosticks commented on GitHub (Jul 30, 2024):
The latest Linux client still connects to the AP on port 40070, you can get some verbose logging out their binary:
I've kind of got spotify-analyse running on my WSL machine but annoyingly I can't catch the whole connection, the first thing I capture is ClientResponseEncrypted.
EDIT: I am being dumb, ClientResponseEncrypted is the interesting bit! It's using
AUTHENTICATION_STORED_SPOTIFY_CREDENTIALS. I think login5 method is the answer. Their app doesn;t ask for your user and pass anymore, it does an oauth thing via your browser.@SuisChan commented on GitHub (Jul 30, 2024):
Isn't this normal behavior? In my case it always worked like that, I mean the first one intercepted was always ClientResponseEncrypted
@kingosticks commented on GitHub (Jul 30, 2024):
yeh sorry, I was being stupid. See edit.
@dspearson commented on GitHub (Jul 30, 2024):
I guess a way to avoid this issue would be to use tokens a la https://github.com/librespot-org/librespot/issues/242 instead. My Rust is not really strong enough today to implement such a thing though unfortunately.
@SuisChan commented on GitHub (Jul 30, 2024):
Hmm, I see. It turns out the fix should be simple(?), login via login5 and then use the received stored credentials
@rgon commented on GitHub (Jul 30, 2024):
@kingosticks I cannot log in on port 4070 either, with the same AP. Linux client.
This is not a windows/linux issue, but rather that the API change is being rolled out progressively, thus not affecting some combination of users/AP sometimes. Annoying to debug indeed...
@kingosticks commented on GitHub (Jul 30, 2024):
So it's an Oauth flow for the first login and then stored creds afterwards. The description at https://developer.spotify.com/documentation/commercial-hardware/implementation/reference/3.203#spconnectionloginoauthtoken seems to support that.
@eladyn commented on GitHub (Jul 30, 2024):
When I checked yesterday, while the desktop version uses OAuth for the login, the mobile (android) client still lets the user input their credentials (together with a hash cash challenge) and uses login5 to log in and get the stored credentials.
@roderickvd commented on GitHub (Jul 30, 2024):
devcontains an implementation to solve the hash cash challenge that works most of the time. Sometimes it cannot solve it in the amount of time, and bails out. It’s not perfect but it works.To trigger the hash cash, you must carefully set the right combination of OS and platform in various locations. I can’t tell you what the “right combination” is anymore but if you want it to work on Linux, then I do remember you have to look at the HTTP user agent in combination with the Mercury API key.
@SuisChan commented on GitHub (Jul 30, 2024):
But it should always work, since it is reverse engineered from an original app, and the code should match
Also it may not solve the challenge in that time, if one use debug build, then yes, it may be slow
or...I don't know, there's not enough data to draw conclusions
@devgianlu commented on GitHub (Jul 30, 2024):
I think they straight up removed the username password login method, for both the AP and Login5, as @dspearson mentioned. I tried the username password authentication with Login5 (which has always worked well in go-librespot) and it still fails.
This is supported by the fact that their own client doesn't let you enter credentials directly anymore, but just sends you to the website.
EDIT: Didn't read about the mobile client still supporting username and password, but that might be removed at some point too, perhaps the best idea is to just embrace the OAuth2 flow.
@devgianlu commented on GitHub (Jul 30, 2024):
Did a quick implementation of the OAuth2 flow to replace username password authentication:
github.com/devgianlu/go-librespot@1e82a27681Seems to be working fine.
@kingosticks commented on GitHub (Jul 30, 2024):
Awesome! OK so the flow is:
codeis returned to appclient-token(can't remember how but we do this already)codefor short-lived access token with POST https://accounts.spotify.com/api/token (usingclient-tokenheader),ClientResponseEncryptedrequest of typeAUTHENTICATION_SPOTIFY_TOKENwith our username and theauth_datais just the access token from step 3? ReceivesAPWelcomeresponse containing long-livedreusable_auth_credentials.client-tokenheader) sendingLoginRequestusingstored_credentialLoginRequestmethod.Is that right @devgianlu ?
I did some of this in #1098 but I ran into problems when I tried to actually stream music. Was I just using the wrong oauth scopes ?!
p.s. for anyone else trying to mitm the linux client, I had to use
/usr/bin/spotify --ignore-certificate-errors.@ejurgensen commented on GitHub (Jul 30, 2024):
OwnTone has an implementation Spotify's OAuth flow + stored credentials that might be a useful reference for you. See for instance login_token() in spotify_librespotc.c. Disregard the login() method, it isn't used, which also means OwnTone hasn't been affected by Spotify's change.
@devgianlu commented on GitHub (Jul 30, 2024):
@kingosticks Yes that's about right. I completely forgot about the
client-tokenthing for the OAuth2 flow and it seems to be working anyway. They might have changed a lot of stuff since #1098, I remember this not working too, but perhaps now it's fixed. The scopes I used I just copied from the deskop client, some might not be required.@kingosticks commented on GitHub (Jul 30, 2024):
Thanks @devgianlu.
I guess one last thing that I am bit confused about is, what stops everyone and their dog who's running a local app (and therefore using localhost as the
redirect_uriparam) using Spotify's desktop app client ID for requesting access+refresh tokens for use with the web API? Presumaby tokens granted this way won't be rate limited.Update:
I found https://github.com/librespot-org/librespot-java/issues/445#issuecomment-1006725762 which also mentions how this wasn't working before. Weird!
@3052 commented on GitHub (Jul 30, 2024):
I just tried https://login5.spotify.com/v3/login and it works perfectly with username/password - using the same code I wrote in March
@kingosticks commented on GitHub (Jul 30, 2024):
This issue is specifically about user+pass with the Mercury/Hermes access point and not login5.
@3052 commented on GitHub (Jul 30, 2024):
why in gods name are you still using Hermes for that? I know at least the Android client has been using login5 for at least 4 months likely longer
@kingosticks commented on GitHub (Jul 30, 2024):
The flow I outlined above is exactly what the (Linux) desktop client does today. Note, still using Hermes.
Obtaining reusable creds from login5 using user+pass is apparently not working, perhaps it's related to the client ID or client info being used. Feel free to share your recipe.
@JoeWilder commented on GitHub (Jul 31, 2024):
librespot just started working for me again, not sure why
@Losses commented on GitHub (Jul 31, 2024):
It seems that Spotify rolled back their code, but probably we should switch to web based oauth login work flow, to follow the pace of Spotify's official implementation.
Server information:
@Laiteux commented on GitHub (Jul 31, 2024):
Can confirm. Works again here as well.
@kingosticks commented on GitHub (Jul 31, 2024):
One issue with that newer method is how to implement it on a headless machine. You can't just paste the oauth URL into a browser running elsewhere as it will redirect afterwards to localhost, which won't work. Unless Spotify allow any redirect_uri to be used with their client ID but that seems unlikely (needs checking). Their flow for headless systems would be device code.
@Losses commented on GitHub (Jul 31, 2024):
That is a headache trouble, programs like
rclonewill recommend users connect to remote machine with port forwarding, but it is not always working, some other solutions pops to my head, and the most practical one is a command line tool, which can help users get their token in the local machine, users can paste it to the remote device which will probably ease the procedure.Anyway, it's hard.
@quantverse commented on GitHub (Jul 31, 2024):
It works again for me now. AP
ap-gew4.spotify.com:4070.@dspearson commented on GitHub (Jul 31, 2024):
It does not work on ap-guc3 so this issue is still relevant. go-librespot with interactive login flow simply provides the callback URI in the terminal, and curl on a headless server is enough for me to make progress, but there are other issues that prevent me from using the go implementation. Alas.
@Laiteux commented on GitHub (Jul 31, 2024):
I personally could not work with manual-OAuth URLs as I aim for a fully automated login process. Therefore, this unfortunately can not be a solution for me, and I'm sure many others.
@kingosticks commented on GitHub (Jul 31, 2024):
Even though it's a one-off operation?!
@Laiteux commented on GitHub (Jul 31, 2024):
Adding such a step to the login process would imo be a significant change from an automatic to manual flow, and be potentially disruptive for many users, for a few reasons:
Frequent disconnections: Perhaps it's just my experience (please let me know if others face this too), but I experience periodic disconnections (every few days) that require restarting my program / auth flow to reconnect to the Spotify API. This issue at least is present on my side when using librespot through DownOnSpot. A manual login step would exacerbate this inconvenience.
Headless machine compatibility: Implementing a manual login would force users of headless machines to develop a method for transmitting the OAuth URL to a device with a browser. This adds complexity and inconvenience to the process.
@devgianlu commented on GitHub (Jul 31, 2024):
@Laiteux The login operation should happen only once manually, then stored credentials can be used for perhaps years to follow.
@devgianlu commented on GitHub (Jul 31, 2024):
@dspearson If it's not something big, we can sort it out!
@Laiteux commented on GitHub (Jul 31, 2024):
I understand that and it sounds right. I am not sure what could be causing my (seemingly specific) issue, then, considering I indeed get randomly disconnected, periodically, every few days.
Credentials are indeed being stored and reused, still I sometimes keep getting randomly disconnected, having to re-auth.
Maybe could it be related to the nature of the project I am using (DownOnSpot)? I am unsure but still would appreciate some guidance. @oSumAtrIX, are you any aware of such a thing?
Perhaps this is a different issue and should be discussed elsewhere.
My point about headless machines (firstly mentioned by @kingosticks here) remains.
@oSumAtrIX commented on GitHub (Jul 31, 2024):
While I haven't delved much into the issue yet, I have definitely come across your findings. Someone else was reporting the same issue (which is the credentials cache not being reused). I think it was discussed in one of the (closed) issues or PRs in the DownOnSpot repository. In addition to that the author that mentioned this issue decided to PR a fix to librespot which I think got merged. That said, if you bump librespot to one of the latest commits (contains breaking changes from last official release), the issue should disappear. The commit may appear in a future release though anyway. I am pulling this all off my memory, so if relevant, please double check!!
@Laiteux commented on GitHub (Jul 31, 2024):
This likely was me, and it did not get merged: https://github.com/librespot-org/librespot/pull/1206 - I did not investigate further after that, as I could not understand what exactly was to be fixed then. The issue remains on my side, so not sure of what to do now. Maybe we can keep discussing it on the PR or on the DownOnSpot issue if there was one (can't seem to find it).
@Losses commented on GitHub (Jul 31, 2024):
@Laiteux
I would like to kindly remind you to be mindful that this project should not be used for piracy purposes, as this violates Spotify's Terms of Service. While the project may have been applied in illegal contexts, it is possible that this was not the original intent behind its creation.
Repeatedly mentioning piracy-related software could prompt Spotify to initiate legal action against the entire toolchain, which would negatively impact other users who are utilizing librespot for legitimate purposes. We have seen similar situations occur in the past.
Therefore, please consider to exercise caution and restraint in your discussions.
@kingosticks commented on GitHub (Jul 31, 2024):
This all just highlights we should add support for the oauth/token flows. Whatever happens to user+pass in the long-term, it's useful to have another alternative anyway and we've discussed it before so maybe we should pick it up again there or in a new specific issue.
I think we can close this given the issue appears to have been temporary and now we're vearing off-topic (sorry for starting that).
@erkr commented on GitHub (Jul 31, 2024):
Please don't close without opening a PR for implementing the oauth/token flow. I guess that Spotify did a rollback, but it will be just temporary to fix something.
@dspearson commented on GitHub (Jul 31, 2024):
Indeed. The username/password flow is removed from the official API and as mentioned in a previous comment it still fails for me. Closing would be premature.
@kingosticks commented on GitHub (Jul 31, 2024):
Sorry, I missed that. I thought it was working for everyone again.
@dspearson commented on GitHub (Aug 4, 2024):
A suggested workaround while this remains broken: set the cache directory when invoking librespot on local machine, do not use --username/--password, which then will use zeroconf authentication with Spotify's official client running alongside it, then copy the librespot cache directory to remote headless server. Invoke with the same parameters on the remote host. The cached credentials appear to work just fine, at least for the moment.
@dspearson commented on GitHub (Aug 4, 2024):
In fact, from further reading of the Spotify Connect documentation it now seems clear to me that the ZeroConf API is the only supported authentication method, and is in fact mandatory for certification. Therefore, probably removing the option of username/password authentication and updating documentation is sufficient. Those that have the more unusual use-case (like me) of having librespot being a Spotify Connect client on a remote headless device that is on a separate network to my usual client (and thus ZeroConf is a pain) can probably live with the added step of initial authorisation locally & deployment of credentials file on the remote target if this is made obvious.
To quote from the Spotify Connect implementation documentation: "The following example uses SpConnectionLoginPassword() to log in. This API exists for testing purposes only."
@Losses commented on GitHub (Aug 4, 2024):
Totally agree
@kingosticks commented on GitHub (Aug 4, 2024):
Just to clarify, Spotify Connect is just one part of this library.
User and password login via login5 (using the android client ID and doing the hashcash stuff) reportedly still works, there's no reason not to support that properly here. Oauth login via login5 (using the desktop client ID) also works just fine and makes sense for some use cases. User and password via Hermes might be on borrowed time but while it still works (for everyone except one person?!), just leave it in, surely.
@poettig commented on GitHub (Aug 4, 2024):
This works perfectly, thank you! 👍
I'm also affected by username / password still not working, also with the use case "librespot running with no spotify desktop in the network". I tested why that could be - turns out Spotify requires me to enter an email OTP when logging in with the remote server's IP - most likely because it is not a residential IP or something along those lines. I would guess that spotify just blocks logins with only username and password via hermes if the IP is flagged for additional authentication.
@dspearson commented on GitHub (Aug 4, 2024):
Yes, sorry I was not explicit. I mean deprecation/removal of this auth method specifically for Connect functionality, since username/password is documented as "only for testing", and has been removed from the latest eSDK release, so if it still somehow works for some people (possibly from partial rollout?), it's likely not to continue to do so and is definitely documented as not for real-world usage/unsupported. Though I think just a note in the documentation about the API changes, and that for Connect one should prefer ZeroConf, would be enough to steer people away from pain.
I admit I was not even really aware of ZeroConf authentication being a thing that existed until the method I was previously using failed, and I started to look for myself at the internals. Initially it was simple enough to get running correctly, and stable enough to be mostly left alone for over a year, that when things didn't work anymore I was basically completely rediscovering how the thing worked and how to use it... a testament to the quality of the project, honestly.
@ghost commented on GitHub (Aug 6, 2024):
Same issue, fails if I use username/password, fails if I use email/password
@roderickvd commented on GitHub (Aug 8, 2024):
I just got this email:
Seems genuine - I mean, why fake it? - and actually a nice acknowledgement that they “see” us, and first active communication from them that I’ve seen.
If there’s anything you’d like me to respond to them, please cook up some text for consideration. Who knows they might respond?
@devgianlu commented on GitHub (Aug 8, 2024):
Just received the same email, feels kinda nice for them to do this.
@Losses commented on GitHub (Aug 9, 2024):
So, maybe librespot will switch to oauth these days?
@michaelherger commented on GitHub (Aug 9, 2024):
Wouldn't auth be irrelevant when librespot is used as a Connect endpoint? It would be authenticated through the app automatically, wouldn't it?
@kingosticks commented on GitHub (Aug 9, 2024):
Yes, but Connect is not the only way to use this library so another mechanism is still required.
There's a PR for oauth at https://github.com/librespot-org/librespot/pull/1309 if anyone wants to try/review/improve.
@microfx commented on GitHub (Aug 9, 2024):
no idea if it's of any interest but since a few hours librespot not working anymore for me.
Tried to remove the username and password arguments but it didn't help.
@dspearson commented on GitHub (Aug 9, 2024):
Sure, you can use zeroconf trivially if the app is on the same network as librespot, which is not a given (wasn't the case for me). I was using username/password for this very reason. Have switched to authenticating locally and transferring the credentials.json elsewhere.
Nice of Spotify to reach out directly.
@kingosticks commented on GitHub (Aug 12, 2024):
We could ask them if username+password login via login5 (using Android client id and doing hashcash stuff) is going to continue to work beyond these "few days"?
@felipemarinho97 commented on GitHub (Aug 12, 2024):
Spotify Connect and snapcast only woks with auth for me, I hope this gets fixed soon
@awsome306 commented on GitHub (Aug 13, 2024):
Same issue here
@michaelherger commented on GitHub (Aug 13, 2024):
Make sure your phone is on the same network as the librespot instance.
@FlipEverything commented on GitHub (Aug 14, 2024):
I am experiencing the same issue. Login with credentials no longer working:
After I removed my credentials from the config then the Spotify Connect Client will start up:
But I cannot discover the client via the Spotify API. I am on the same LAN. Until now I used the
GET /me/player/devicesrequest and the Spotify Connect Client (raspotify) showed up and I could automatically start up a selected playlist, etc. What can I do to restore this behaviour?@tig3rmast3r commented on GitHub (Aug 14, 2024):
does anyone gave a try to this pr yet?
@noahhaon commented on GitHub (Aug 14, 2024):
Yes I did this to generate
credentials.jsonwhich I use on a headless librespot with discovery off-Oand it has been working great.@neekz0r commented on GitHub (Aug 14, 2024):
Yeah, I just got bit by this too. I'm also fairly sure zeroconf work around mentioned here won't work if its on docker.
@abiding9072 commented on GitHub (Aug 14, 2024):
I'm using headless on a docker container. I generated the credentials.json on another system then placed in a docker volume linked to a local folder without issue on my headless system.
@neekz0r commented on GitHub (Aug 14, 2024):
Won't the creds rotate on a (semi)regular basis?
@michaelherger commented on GitHub (Aug 15, 2024):
The
credentials.jsonin my main installation has a timestamp from January 1 2023.As for docker: you could run the container in host mode instead of the default bridge mode (which does come with some drawbacks). Or probably expose some additional ports?
@Laiteux commented on GitHub (Aug 15, 2024):
Can anybody else confirm if this is failing again? Unable to conclude from previous recent comments, but I've been hitting the error again on my side for the past few days.
@capnfabs commented on GitHub (Aug 15, 2024):
Seems to be failing again! Adding another data point: I noticed that user/pass login was broken last night, and got a password reset email from Spotify at some point in the night "due to detected suspicious activity." librespot still works great without user/pass login.
@noahhaon commented on GitHub (Aug 15, 2024):
Yes I was getting this repeatedly too, every day or so. So far the cached credentials seem to work and I don't get the password reset notifications via email anymore
@michaelherger commented on GitHub (Aug 15, 2024):
Spotify even announced the end of username/password auth here: https://github.com/librespot-org/librespot/issues/1308#issuecomment-2276196094. It's unfortunate Github would hide that posting by default...
@psaumur commented on GitHub (Aug 15, 2024):
Works on PC (my primary OS)
Works on Debian (Took Username/Password, no issue)
Try to enter credentials on Linux Mint, authorization fails - fail enough times and Spotify disables your account and resets your password. Not cool.
You can, however, copy the credentials.json file, from Debian to Mint, and it works again - IF you can get it to authorize (even typing them in by hand can fail the auth!!!)
Frustrating with the disabling of account due to failed auth, though.
@dspearson commented on GitHub (Aug 17, 2024):
As others have already mentioned, the credentials generated via the zeroconf authentication mechanism appear long-lived and is the officially sanctioned way to authenticate Spotify Connect devices. I noted some people using downstream clients (those depending upon librespot) were having difficulty in generating the
credentials.jsonfile, so I thinly wrapped just this functionality and tried to make it as trivial to use as I could think; maybe it helps others who stumble here with similar problems.This bug is no longer relevant for me at least. I will defer to maintainers for closing this when appropriate, given that there's still plenty of people here that seem to have trouble. My thanks to all those that helped thus far!
@psaumur commented on GitHub (Aug 18, 2024):
"While running on the same network as a Spotify client..."
Does this only work with a locally installed application and not the browser app?
Edit: Downloading the Linux Spotify client, running Dominic's application in the background, pulls out working credentials. Everything works again (for ncspot)
@andrewCohn commented on GitHub (Aug 18, 2024):
Maybe a stupid question, but how exactly do I authenticate with the credientals.json file?
Edit: -C "pathToDirectoryWithCreds" worked for me, and allowed me to configure my daemon
@noahhaon commented on GitHub (Aug 19, 2024):
Note that you have to disable zeroconf
-Oand use the-Cparameter to point to the directory with thecredentials.jsonfile for it to be used.@kingosticks commented on GitHub (Aug 19, 2024):
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.
@andrewCohn commented on GitHub (Aug 19, 2024):
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?
@noahhaon commented on GitHub (Aug 19, 2024):
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.
@kingosticks commented on GitHub (Aug 19, 2024):
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.
@rwjack commented on GitHub (Aug 21, 2024):
Anyone know how to pass the
credentials.jsonfile from @dspearson's tool to Snapcast/Librespot?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
-Oand-Cto it properlyUpdate:
-Ois disable discovery, so no need for that.-Cis the cache dir, which can directly be passed to the Snapcast stream variable&cache=/data/librespot(Make sure to create the dir and store credentials.json there)On another note, I'm having trouble running snapcast with the latest version of alpine... Just get a segfault... https://github.com/badaix/snapcast/issues/1275
@roderickvd commented on GitHub (Aug 21, 2024):
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.
@michaelherger commented on GitHub (Aug 21, 2024):
Thanks for your effort, @roderickvd. Unfortunately I happen to know that they have an issue with the lack of reporting (see https://github.com/librespot-org/librespot/discussions/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 :(.
@roderickvd commented on GitHub (Aug 21, 2024):
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...
@fraintt commented on GitHub (Aug 25, 2024):
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:
source = librespot:///librespot?name=Spotify&bitrate=160&devicename=SoundSystem&cache=/data/librespot?
Thank you in advance!
@AdrieVanDijk commented on GitHub (Aug 31, 2024):
I only removed the -u and -p parameters and it worked again, although it gave a warning:
Unable to get client token. Trying to continue without...So why do I need a credentials.json ?
@DarpNagarsheth commented on GitHub (Aug 31, 2024):
Okay I'm able to get my cred json file but not login, might be newbie question but would love some help.
.
But I can see the way authentication is done now is changed, it was
.
{ "username": "",
"credentials": "",
"type": "AUTHENTICATION_STORED_SPOTIFY_CREDENTIALS" }
.
Now it is
.
{ "username": "",
"auth_type": 1,
"auth_data": "" }
.
how do I adapt my old login to this? I'm using zspotify https://www.reddit.com/r/Piracy/comments/15irsee/ive_updated_zspotifyexe_to_fix_its_bugs_from_the/
.
.
Do I update librespot.core? because that's what's doing the auth?
@SuisChan commented on GitHub (Aug 31, 2024):
Login challenge (hashcash)? It has always been like that
@3052 commented on GitHub (Sep 1, 2024):
OK I have a working email/password implementation, again it was just the addition of the user-agent basically:
https://github.com/3052/platform/tree/v1.4.9/spotify
@xdfwers commented on GitHub (Sep 10, 2024):
@DarpNagarsheth Have you solved the issue, i am facing the same issue using zspotify.
@kingosticks commented on GitHub (Sep 10, 2024):
There is no support for that tool here. Thanks.
@curiousercreative commented on GitHub (Oct 12, 2024):
I don't agree with the tone of the previous comment, but I've always been curious why the repo doesn't publish releases. Fortunately, I find the latest is often packaged for alpine edge, but the versioning is unclear. Has this been discussed previously and there's a reason new releases aren't created and published?
@roderickvd commented on GitHub (Oct 12, 2024):
It's not by any policy but by the way things go. Mostly because:
This project needs more contributors and maintainers - myself I don't use Spotify or even have an account anymore;
Given bullet 1 and the not insignificant installed user base, I want to be sure that what we release is stable;
0.5 presents some major changes and until recently was hardly battle-tested, so of higher risk.
By the way, I am extremely happy with the recent influx of contributions! It's ensured 0.5 is tested and got a couple of much needed fixes in.
So yes I intend to release 0.5 soon, work and family life also permitting, with either of the PRs in to fix the frequent disconnections.
@rwjack commented on GitHub (Oct 13, 2024):
I don't get why this guy is being downvoted. Someone needs to step up and publish a release. There will always be bugs and imperfections that can be straightened out later.
No release means less actual testing. Librespot is not a "production service", everyone who cares about uptime will 200% test before blindly updating to 0.5.
And the whole delay in creating a release is just making everything worse, according to all SE guidelines. Make small changes, perform quick tests and publish releases often - the exact opposite of what we have now.
@shanemeagher commented on GitHub (Oct 13, 2024):
Guys calm down. I've been following this project since the early days and here's some context.
@roderickvd isn't the original creator, just the person who stepped up to progress it and manage it when no one else could be bothered. He had a Spotify account once and has moved to another service now but he keeps managing the project because nobody else offered to take it over
@devgianlu commented on GitHub (Oct 13, 2024):
Please be kind to those that maintain open source projects in their free time. This is not a job for many and focusing on a project you don't use anymore feels like wasted time.
This kind of bad attitude towards open source projects will not get you or the project anywhere.
@michaelherger commented on GitHub (Oct 13, 2024):
Please re-consider your attitude: this software is provided by volunteers spending their spare time, night and day, on the product. They receive nothing for all the work and hassle and time spend. If you p... them off with your angry attitude, you won't get anything back. They will leave and you can continue to be angry for yourself.
If you know how much effort it is to release such a product, then just build it yourself. If you don't know how to do it, then how can you judge the effort required?
@noahhaon commented on GitHub (Oct 13, 2024):
@ManiArasteh build it yourself. If you can't, I will compile it for you for 200EUR.
@noahhaon commented on GitHub (Oct 13, 2024):
@ManiArasteh so you built your app with dependencies on open source software, whose unpaid maintainers you are being extremely demanding and rude to. And now you are not getting what you want. Sounds like a "you" problem my dude.
Anyhow, offer stands if you want me to build it for you. Just let me know what platform and you can paypal me 300EUR - a special discount for you, today only.
@roderickvd commented on GitHub (Oct 13, 2024):
👮 locking this thread.
Thanks for the sensible comments and taking note of what I already said in https://github.com/librespot-org/librespot/issues/1308#issuecomment-2408621833. Let's focus on getting either #1357 or #1359 in.
@ManiArasteh I will not accept your behaviour. This is your last and only warning before I block you.