ignore credential cache if no username is specified
As mentioned in #948 (thanks @aanno and @mas-4), zeroconf authentication fails if caching is enabled and credentials of a different user are cached. This adds extra handling for this case.
This PR has not yet been tested!
I'm not confident at all that I understand what's going on (I have only ever written a rust hello world) but here's what I think after a trial:
- The original issue is that when user b connects to the device after user a has disconnected the client crashes (exits?) and systemd restarts it (which takes 12 seconds because
RestartSec=12in my systemd service). This clears the in memory cache and allows a new user to connect. - To test whether the same problem persists here I checked out your PR and did a clean build
cargo build. - I started spotifyd the same way as within my systemd service (
./target/debug/spotifyd --no-daemon --config-path ~/spotifyd.confwhere I took myspotifyd.conffrom my raspberry pi and just changed the name to debug so I don't clash with my local.
Given all that, the problem persists in this branch. I connect with phone a, disconnect, connect with phone b, crash.
I have just built and tested the branch eladyn:zeroconf_cache_fix and I'm able to say that using spotifyd with more than one user is possible now, even with caching enabled.
Thank you for fixing this, @eladyn !
Thank you both for having a look!
@mas-4: You're right, this PR does not try to fix the re-usability issue without restarting spotifyd. It only prevents the credential cache from clashing with zeroconf authentication.
@aanno, thanks for testing it. Marked as ready for review so that it hopefully can be merged soon.
I think, this is no longer necessary and is now working as intended on master.
Well, I tried this compiling the code on master. It's working when the spotifyd audio cache feature is off (no_audio_cache = true) with a working/used cache_path = "cache_directory".
However, when the spotifyd audio cache feature is on (no_audio_cache = false), my other family members could not even see the device (on the spotify app).
I guess that this is not the intended outcome (and it comes to me as surprise as well!).
Thanks for your report, I'm going to take a look, if I can find out what's going on there soon!
@aanno I just got around to trying it myself and I can confirm this bug. For me, it's even happening with no_audio_cache set to true. I'll try to push a fix soon. Thanks for your help!