Spotify disabled username/password authentication
Jump to workarounds: https://github.com/mopidy/mopidy-spotify/issues/394#issuecomment-2285831264
noting that Spotify disabled username/password authentication, which affects playback in 2024 on the https://github.com/mopidy/mopidy-spotify/tree/v5.0.0alpha branch,
users will see errors similiar to
failed to start: Login failed with reason: Bad credentials
ERROR spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:328:gstspotify::spotifyaudiosrc::imp:<source> failed to start: Login failed with reason: Bad credentials
WARN basesrc gstbasesrc.c:3134:gst_base_src_loop:<source> error: Internal data stream error.
WARN basesrc gstbasesrc.c:3134:gst_base_src_loop:<source> error: streaming stopped, reason error (-5)
WARN oggdemux gstoggdemux.c:4775:gst_ogg_demux_send_event:<oggdemux0> error: EOS before finding a chain
WARN oggdemux gstoggdemux.c:2550:gst_ogg_demux_sink_event:<oggdemux0> EOS while trying to retrieve chain, seeking disabled
since this is an upstream issue with https://github.com/librespot-org/librespot/issues/1308 a solution will be multi-tiered,
as always, ty @kingosticks, for your work on this
Originally posted by @troyxmccall in https://github.com/mopidy/mopidy-spotify/issues/110#issuecomment-2284230854
Thanks for adding this here also.
I would have thought things will continue to work for existing users because we support "cached credentials". Only the very first login actually uses your user and password. This does assume you are persisting the contents of Mopidy's
data_dirwhere we store that blob. The default config location should ensure that's the case. I can replicate the problem if I move my cached creds elsewhere but it's still working otherwise.Obtaining cached credentials (via a custom build of librespot, or similar) and moving them into this directory is a work-around.
Originally posted by @kingosticks in https://github.com/mopidy/mopidy-spotify/issues/110#issuecomment-2284282360
As already mentioned, this ultimately needs fixing in librespot. I have submitted a PR there to do that, hopefully it'll be merged when the maintainer has time. I'd appreciate review/feedback anyone has on that work but please don't hassle them there, everyone is busy and it's holiday season too - thanks Spotify! Once that (or something like it) is merged, we'll need to get support into gst-plugin-spotify. Depending what that support looks like, we may then also need to make changes to Mopidy-Spotify. As you can see, there are multiple projects involved so don't expect this to happen tomorrow. We could provide a custom build but I am reluctant because I'm not sure what gst-plugin-spotify will look like and I don't want to support another version of everything, even if it is short-term.
In the meantime, there is a workaround. You ultimately need to obtain a "cached credentials" file and drop this into your Mopidy-Spotify data directory (typically $HOME/.local/share/mopidy/spotify/credentials-cache/credentials.json or /var/lib/mopidy/spotify/credentials-cache/credentials.json). You can generate this file by running librespot and authenticating via "discovery" mode (AKA zeroconf).
- Download rust and clone librespot.
- From the librespot directory do
cargo run --no-default-features -- --cache . - Use an official Spotify app (on the same network) to connect to the running librespot device using Spotify Connect
- You'll then find a new
credentials.jsonfile in the librespot directory that looks something like
{"username":"fred","auth_type":1,"auth_data":"LOADOFSEEMINGLYRANDOMCHARACTERSBLAHBLAGBWOOTWOOt=="}
- Copy this file into the appropriate Mopidy-Spotify directory as mentioned above.
If you cannot use Spotify Connect for whatever reason, you can alternatively get a credentials.json file using the new OAuth flow feature in the dev librespot branch: cargo run --no-default-features -- --cache . --enable-oauth.
As already mentioned, this ultimately needs fixing in librespot. I have submitted a PR there to do that, hopefully it'll be merged when the maintainer has time. I'd appreciate review/feedback anyone has on that work but please don't hassle them there, everyone is busy and it's holiday season too - thanks Spotify! Once that (or something like it) is merged, we'll need to get support into gst-plugin-spotify. Depending what that support looks like, we may then also need to make changes to Mopidy-Spotify. As you can see, there are multiple projects involved so don't expect this to happen tomorrow. We could provide a custom build but I am reluctant because I'm not sure what gst-plugin-spotify will look like and I don't want to support another version of everything, even if it is short-term.
In the meantime, there is a workaround. You ultimately need to obtain a "cached credentials" file and drop this into your Mopidy-Spotify data directory (typically
$HOME/.local/share/mopidy/spotify/credentials-cache/credentials.jsonor/var/lib/mopidy/spotify/credentials-cache/credentials.json). You can generate this file by running librespot and authenticating via "discovery" mode (AKA zeroconf).
- Download rust and clone librespot.
- From the librespot directory do
cargo run --no-default-features -- --cache .- Use an official Spotify app (on the same network) to connect to the running librespot device using Spotify Connect
- You'll then find a new
credentials.jsonfile in the librespot directory that looks something like{"username":"fred","auth_type":1,"auth_data":"LOADOFSEEMINGLYRANDOMCHARACTERSBLAHBLAGBWOOTWOOt=="}
- Copy this file into the appropriate Mopidy-Spotify directory as mentioned above.
If you cannot use Spotify Connect for whatever reason, you could clone my librespot branch instead and get your credentials.json via the new OAuth flow with
cargo run --no-default-features -- --cache . --token ''.
I am getting this error when trying the last option: Error parsing command line options: Unrecognized option: 'token'
Does 'token' appear as an option when you run with --help? If not, you're not using my fork. Also note the version should be '0.5.0-dev 27b2b59'.
cargo run --no-default-features -- -c . --help
...
librespot 0.5.0-dev 27b2b59 (Built on 2024-08-13, Build ID: 2q9wcmIs, Profile: debug)
An open source client library for Spotify, with support for Spotify Connect
https://github.com/librespot-org/librespot
Usage: target\debug\librespot.exe [<Options>]
Options:
...
-k, --token TOKEN Spotify access token to sign in with. Use empty string
to obtain token.
Looks like cloning the git was giving me the wrong version indeed. Grabbed the zip and that sorted it all out. Thanks, working great now.
Thanks a lot for this quick fix. Surprisingly it worked well yesterday adding manualy the credentials.json to my local folder... but today I get this error starting mopidy and its extensions : pi mopidy[13812]: ERROR [SpotifyBackend-9] mopidy_spotify.web OAuth token refresh failed: invalid_grant Grant has been revoked. pi mopidy[13812]: ERROR [SpotifyBackend-9] mopidy_spotify.web Failed to load Spotify user profile
I retried the procedure without success, a bit weird... Is somebody experiencing a similar issue?
PS : I guessed that values in mopidy.conf are not supposed to be removed (username, password, client_id, client_secret)
PS : I guessed that values in mopidy.conf are not supposed to be removed (username, password, client_id, client_secret)
The username and password fields won't actually be used once you've got a credentials.json in place. The client_id and client_secret might need updating if Spotify have reset your credentials? These are used by the mopidy_spotify.web module to access your account data. You can get new ones at https://mopidy.com/ext/spotify/
Hi, I tried the Spotify Connect workaround but unfortunately without success. Is there any log entry to verify the use of the credentials.json file by Mopidy? Thanks
No. You could try the gstreamer logs: GST_DEBUG=3,*spotify*:6 mopidy.
The username and password fields won't actually be used once you've got a credentials.json in place. The client_id and client_secret might need updating if Spotify have reset your credentials? These are used by the
mopidy_spotify.webmodule to access your account data. You can get new ones at https://mopidy.com/ext/spotify/
Well done, I reset the values and that fixed the problem. Cheers
Found my problem. Within mopidy.conf, I had the spotify login mail address but credentials.json contained the spotify username. Updated mopidy.conf and now its working.
Oh, excellent find. Thanks
Thanks @kingosticks for your work. Unfortunatly i can not get it to work. I created the credentials.json on a windows machine and copied it to a linked folder on my server, where mopidy runs in a docker container. I also did an update of the clientID and secret. It still gives me the "bad credentials" error. Is it even possible to create the credentials on another machine or does it need to be the machine were mopidy runs? I gues then its not possible to do it within the container!? Thanks a lot!!!
I would guess it might need to be the same OS (e.g. windows, mac, Linux), because the client ID used to generate the credentials file is OS-specific. But that's a guess.
As per my early comment with workarounds, if you can't use zeroconf on your server, use my forked version and do the oauth flow in headless mode cargo run --no-default-features -- --cache . --token "" --token-port 0.
Spotify disabled username/password authentication
no, they didn't. you just have to specify user-agent
Great, thanks, that's super helpful.
So steps for me to make this work were a combination of multiple things mentioned in this thread:
- get a new valid
credentials.jsonusing LibreSpot when connecting to it from an official Spotify client - Update
client_idandclient_secretvalues from https://mopidy.com/ext/spotify/ - Update the username field in
mopidy.conffrom my email address to the username mentioned incredentials.json. It seems to be an auto-generated username, there is no way I would be able to guess or know it
I hope this process can be simplified again at some point in the future because this was a bit of a hassle :sweat_smile:
Hmm, has anyone else encountered Spotify flagging the mopidy connection as suspicious and resetting their password? The first time this happened it took a while and I didn't associate it with this method. But yesterday Spotify locked my account down within about 8 hours of setting this up. I'll try again, but am now discouraged.
It's happened to some users of librespot (and us by extension) because our software is still using their now deprecated username and password authentication flow. It's pretty stupid they're doing this (they gave us very little notice and didn't mention they'd also do this), but that's Spotify for you.... I've now got token based auth working but it relies on code that's not yet merged/released upstream. Hence it's slow. But it's coming and then we'll be able to remove the need for username and password entirely. Which is great for everyone.
Users that had working setups before should still be working because we've also been using "cached credentials", this login method is used in preference to user/pass auth. But I don't think it works for people with weird (Facebook) accounts where the username they log in with doesn't match their "real" Spotify username.
This entire mess is an effort by Spotify to increase account security and we're doing our best to catch up. Personally I have no idea why anyone would want to steal Spotify account credentials, presumably nobody is refusing their passwords in 2024... If you're worried about using your account with Mopidy-Spotify, all the software is available to view and you can build gst-plugin-spotify yourself from source. Spotify themselves are incapable of offering software like this for whatever internal reasons, we're incredibly lucky to have alternatives to their client. But all those alternative clients are based around unofficial software (librespot and its clones). I don't think Spotify intended to scare anyone away from using librespot. After all, they did proactively reach out to the project with a heads-up about the upcoming change. I think they just make a lot of mistakes.
I should also add, cached credentials will also not work if you've managed to configure Mopidy incorrectly. There is currently zero checking and logging of cached credentials usage so it's not obvious when this is happening.
Thanks for the quick reply @kingosticks ... my discouragement was not fear of using my account with Mopidy-Spotify, but bothering to keep this clunker running with mopidy at all. Also, I think you're right ... I definitely have an OG "weird" Facebook account ID for my username, so that very well may be part of the calculus here.
Thanks again for the help!
I'm also looking forward to this clear, non-username/password auth ... Phonieboxes are down now for over a year for me ... I also have to add that this non-working auth mechanism comes with another unpleasant side-effect: The Account used for the Phoniebox gets locked each time the box boots up. Most certainly because the unsuccessfully auth is treated like some Brute-Force attack and account security kicks in.
I understand the frustration, but the auth problem is relatively recent. The issues in the project over the last few years have been due to all kinds of things. And that's inevitable when Spotify leaves us to reverse engineer everything, and changes stuff over time. I hope that fully moving to librespot, and me working on both (if only temporarily, I cannot keep this up) will help get us back on track. I think PhonieBox are also in a period of change so it's unfortunate timing. I did look at helping a while back but it seemed most of the focus was on their new, non-spotify flavour. Can look again when this is working and stable. I have a potential PhonieBox user of my own to motivate me.
Just brainstorming here: I installed "Volumio" yesterday, which also is a Debian based MediaBox, but with a different focus than the Phonieboxes have. Anyways: They claim to have a:
[...] new, totally rewritten (literally), perfectly working plugin for Spotify
I gave it a try and yes: You have to auth using Spotify's Standard-Auth mecha and don't have to create some ClientID and Secret manually; nor does it save the username or password. Also, It's working like a charm!
Spotify support has to be downloaded as a Plugin from here. From the filename, it looks "familiar": vollibrespot
Maybe that's something that also is implementable in Phoniebox?
That's cool. Although I have my own personal opinions on the value of fragmenting the eco system with yet another rewrite but there you go. Having zero compatibility/technIcal-debt is very nice to have.
We should also be able to get rid of our client ID and secrets too also. That is a hangover from long ago, before Spotify support the oauth PKCE flow. See... isn't it nice to rewrite from scratch. I'm not actually jealous, that's a huge amount of effort.
And what about spotify making login connection suspicions? I had to reset my password couple of times because spotify thinks we are doing something fishy. :)
That's cool. Although I have my own personal opinions on the value of fragmenting the eco system with yet another rewrite but there you go. Having zero compatibility/technIcal-debt is very nice to have.
We should also be able to get rid of our client ID and secrets too also. That is a hangover from long ago, before Spotify support the oauth PKCE flow. See... isn't it nice to rewrite from scratch. I'm not actually jealous, that's a huge amount of effort.
Ohhh, it's based on librespot-go. I take it all back, the developer is that has been around and helping for years. That's great news.
@alanmilinovic as I said earlier:
because our software is still using their now deprecated username and password authentication flow
The new version has that fixed. It'll be released soon.
@alanmilinovic as I said earlier:
because our software is still using their now deprecated username and password authentication flow
The new version has that fixed. It'll be released soon.
Very nice, happy to test it.
Please put this in a separate issue. It does not belong here.