Spotifyd/spotifyd

Credential cache is ignored by default

9ary opened this issue · 2 comments

9ary commented

Description
I do not store any credentials in my configuration file because I manage it in a public repo. Previously, starting spotifyd once with credentials on the command line would be enough to stay logged in permanently. It seems #1121 changed this behavior.

This is particularly annoying, because the "username" spotifyd expects is not the email address that is associated with my account, even though that is a valid way to log in. Additionally, spotify does not actually let you choose your username, so it has to be looked up (either from the cache file, or on the spotify website).

I rely on explicit login because I use the website (open.spotify.com) to control playback on my desktop machines. The website is unable to use zeroconf to discover spotifyd, so this forces me to use my phone to initiate the playback session.

A workaround is to use jq to read the username from the cache like so:

username_cmd = "jq -r .username ${cache_path}/credentials.json"

To Reproduce

[global]
backend = "pulseaudio"
bitrate = 320
cache_path = "/home/novenary/.local/share/spotifyd"
no_audio_cache = true
normalisation_pregain = 0
use_mpris = true
volume_normalisation = true
zeroconf_port = 4444

$ spotifyd --no-daemon --config-path /nix/store/48rlijsg02v713kw5bmiw2675rv8d9yl-spotifyd.conf

Expected behavior
The change in behavior is a breaking change, hence this is filed as a bug and not a feature request. I don't particularly care to have it reverted, but one or more of the following solutions should be offered:

  • remembering that the user explicitly logged in
  • an explicit option to force the exclusive use of cached credentials or zeroconf
  • allowing cached credentials to coexist with zeroconf in a graceful way, if possible (ideally, I should be able to "pair" spotifyd with my account by using zeroconf once, and then rely on cached credentials for future use)

Logs

Click to show logs 
Loading config from "/nix/store/48rlijsg02v713kw5bmiw2675rv8d9yl-spotifyd.conf"
No username specified. Checking username_cmd
No username_cmd specified
No password specified. Checking password_cmd
No password_cmd specified
No proxy specified
Using software volume controller.
no usable credentials found, enabling discovery

Compilation flags

  • dbus_mpris
  • dbus_keyring
  • alsa_backend
  • portaudio_backend
  • pulseaudio_backend
  • rodio_backend

Versions (please complete the following information):

  • OS: NixOS 23.05
  • Spotifyd: 0.3.5
  • cargo: 1.69.0
eladyn commented

Thank you for raising this.

I generally see your point. However, I would argue that for your specific use case, there are already several options that should all fix your problem.

  • Using the keyring. spotifyd supports using the system keyring for retreiving credentials through dbus. See the docs for further details.
  • By just providing the username, spotifyd still queries the cache for credentials (as you wrote).

Both solutions require you to somehow provide the username. If you don't want to put it directly in the config file, you can either use the workaround you posted or put it in a separate file and do a simple cat $file as username_cmd.

In theory, the third option you gave

allowing cached credentials to coexist with zeroconf in a graceful way, if possible (ideally, I should be able to "pair" spotifyd with my account by using zeroconf once, and then rely on cached credentials for future use)

should already be possible today, but currently doesn't work due to a bug, as I just noticed. (We're not caching credentials anymore.) As soon as that is fixed, you should just be able to put your username or the line you posted in your config and spotifyd should start discovery if the cache doesn't exist (and save the credentials as soon as a connection comes in). Otherwise, it will just use the cached credentials. (Edit: See #1214)

Would any of these suit your needs?

9ary commented

Thank you for responding!

  • Using the keyring. spotifyd supports using the system keyring for retreiving credentials through dbus. See the docs for further details.

The keyring is indeed appropriate for this but it's not viable in every scenario. I use sway, rather than a desktop environment, so I don't actually have a keyring implementation available for now. It is also not suitable when running spotifyd as a system daemon (in embedded or server setups).

As long as it's just one of the available options though, it is perfectly acceptable.

  • By just providing the username, spotifyd still queries the cache for credentials (as you wrote).

Both solutions require you to somehow provide the username. If you don't want to put it directly in the config file, you can either use the workaround you posted or put it in a separate file and do a simple cat $file as username_cmd.

Yeah, the problem I have with that is, as I've explained, that the username isn't very good UX. It isn't the way most users log in, because it's a randomized and unchangeable string. I'm not strictly opposed to using it, but it would also be nicer not to have to hardcode it anywhere.

As far as reading the cache with jq is concerned, I don't think it's the best long-term solution:

  • the cache file is an implementation detail rather than a public interface, so reading it directly feels like a hack (if it's guaranteed to be stable though, I don't hate it)
  • spotifyd is reading that file anyway, so it should be able to figure out the username from there

In general, I think the behavior of comparing the username from the command line or config file to the one in cache is also a bit confusing compared to an explicit option to use cached credentials.

As soon as that is fixed, you should just be able to put your username or the line you posted in your config and spotifyd should start discovery if the cache doesn't exist

I'm drifting a bit off-topic here, but is it possible to keep discovery enabled even when using explicit or cached credentials?