spotifyd
spotifyd copied to clipboard
Get password from KeePassXC via secret-tool
Description I'd like to use KeePassXC's integrated secret service to store the password and have spotifyd successfully retrieve it (via secret-tool).
Doing secret-tool lookup username
To Reproduce
- Configure KeePassXC as secret service,
- Insert entry to wallet via cmd line from the wiki
- Start spotifyd --verbose --no-daemon
- See: Checking keyring for password
Expected behavior Give me a clear indication if login worked or not.
Logs
spotifyd --no-daemon --verbose
Loading config from "/home/user/.config/spotifyd/spotifyd.conf"
CliConfig { config_path: None, no_daemon: true, verbose: true, pid: None, shared_config: SharedConfigValues { username: Some("taken out for privacy"), username_cmd: None, password: None, password_cmd: None, use_keyring: true, use_mpris: Some(true), on_song_change_hook: None, cache_path: Some("/home/user/.cache/spotifyd"), no-audio-cache: false, backend: Some(PulseAudio), volume_controller: None, device: None, control: None, mixer: None, device_name: Some("Device"), bitrate: Some(Bitrate160), initial_volume: None, volume_normalisation: true, normalisation_pregain: Some(-10.0), zeroconf_port: None, proxy: None, device_type: Some(Computer) } }
Found user shell: Some("/bin/bash")
No password specified. Checking password_cmd
No password_cmd specified
No proxy specified
registering event source with poller: token=Token(0), interests=READABLE | WRITABLE
Using software volume controller.
registering event source with poller: token=Token(1), interests=READABLE | WRITABLE
Zeroconf server listening on 0.0.0.0:41475
registering event source with poller: token=Token(2), interests=READABLE | WRITABLE
registering event source with poller: token=Token(3), interests=READABLE | WRITABLE
Checking keyring for password
- OS: Artix Linux eNTi 5.17.4-256-tkg-bmq #1 TKG SMP PREEMPT Fri, 22 Apr 2022 07:10:01 +0000 x86_64 GNU/Linux
- Spotifyd: 0.3.3-1
Hi and thank you for the report!
Give me a clear indication if login worked or not.
This should be addressed in #1041 or (in a better way) in #1059. The latter would give you messages like:
# spotifyd --no-daemon
Loading config from "/home/user/.config/spotifyd/spotifyd.conf"
No password specified. Checking password_cmd
No password_cmd specified
No proxy specified
Using software volume controller.
no usable credentials found, enabling discovery
-- keeps running --
# spotifyd --username "invalid" --password "invalid" --no-daemon
Loading config from "/home/user/.config/spotifyd/spotifyd.conf"
No proxy specified
Using software volume controller.
Connecting to AP "ap.spotify.com:443"
failed to connect to spotify: Login failed with reason: Bad credentials
-- exits --
Still, I agree that the keyring functionality itself could be a bit more verbose about whether it found a password or not.
Judging from your logs, it seems that it didn't find anything in the keyring and didn't try the login, but I'm not entirely sure. Otherwise, it should show at least the Connecting to AP "..."
part. Would you be able to check if running the following with <username>
being the username
in spotifyd
's config returns anything?
secret-tool lookup application rust-keyring service spotifyd username <username>
I haven't tried the Secret Service provided by KeepassXC yet, so it may as well be an issue on that side. Hope this helps you somehow!
I found the problem of spotifyd not actually working when it requests the password from keepassxc. The problem occurrs when we have the access to the database configured in keepassxc to always ask for confirmation when accessing the database entries. I guess when spotifyd when asks doesn't know how to deal or understands the database being locked.
Temporarily disabling access confirmation on keepass side, allows the spotifyd to actually fetch the password and properly initialize.
Looks like this is related to the upstream implementation of get_password(), not anything with spotifyd. This issue goes into greater detail https://github.com/hwchen/keyring-rs/issues/84
In the meantime, this is what needs to be unchecked in KeepassXC:
Thanks @\vascorsd !
Thank you, @dryya, for linking to that issue! That indeed seems like it should solve our problem once a fix is released.
I was scratching my head over this so hard. This solved the issue for me. Thanks!