Persisting credentials across container restarts when using WebUI provider

[kusold]

Using the WebUI provider for both passwords and MFA, when I restart the container I need to reenter my password. I have /cookies mounted as a volume and I can see icloudpd writing file to it.

How can I persist my authentication across restarts? I'd like to not pass my password in as a command until #768 is implemented.

Potential related issues I found:

• Struggling with Auth and Docker #671
• Authentication persistence (bug?) #1005

[AndreyNikiforov]

Curious what are the most common cases of restarting container? How often does that need arrise?

keyring is the secure way to save password. don't know how to use it from container though.

[kusold]

Some potential scenarios that cause the container to restart:

• Updating the image
  • I use Renovate Bot to update my images, so this would occur on every release.
• Modifying config, such as the docker command
• If running on K8s, your application should expect to restart -- this is not my scenario, but a potentially valid usecase.

Is the WebUI able to persist to the keyring? If so, I can turn the location into a volume mount. The prior issues I linked mentioned the keyring being stored at ~/.local/share/python_keyring.

[AndreyNikiforov]

Some potential scenarios that cause the container to restart

All make sense. I am wondering how often these occur, so we can understand "severity" of the issue and balance it against dev+complexity of solutions. May be using ENV vars with click is an easy/easiest path...

Is the WebUI able to persist to the keyring?

I vaguely remember contemplating the idea to delegate credential persistence to the browser (same way as browser stores password for all web sites). Did not do much research though.

[kusold]

For services that I run as docker images, I pin to specific image versions. I then use renovatebot to open PRs to update the images version when there is a new release. My systems pull these updates nightly and if the image has changed then it pulls the new image and restarts.

This project has recently been releasing twice a month 👏.

I believe that accepting ENV vars would fix this because I could then pass my password in via a variable and MFA would use the /cookies directory. I'm hesitant to do this now, because I don't want my password to be exposed via process lists.

[boredazfcuk]

I solved this in my container by addding XDG_DATA_HOME=/config to the Dockerfile so that ~/.local/share/python_keyring becomes /config/python_keyring and persists across container re-creations (if you have a persistent volume mapped to /config)... You can add the variable at runtime with something like this:

docker run -it --rm --name icloudpd -v $(pwd)/config:/config -v $(pwd)/data:/data -e TZ=America/Los_Angeles -e XDG_DATA_HOME=/config icloudpd/icloudpd:latest icloudpd --cookie-directory /config --directory /data --username [email protected] --watch-with-interval 3600

[kusold]

Thank you. The keyring is the way to maintain persistence.

Instead of using the webui, I manually run this when my creds expire:

podman run \
-it \
--rm \
  --name=icloudpd-auth \
-e TZ=Etc/UTC \
-e XDG_DATA_HOME=/config \
-p 28082:8080/tcp \
-u 4000:4000 \
-v /mnt/data/Photos/iCloud-Backup:/data \
-v /var/lib/icloudpd:/config \
icloudpd/icloudpd:latest \
icloudpd \
--directory \
/data \
--cookie-directory \
/config/cookies \
--password-provider \
keyring \
--password-provider \
console \
--mfa-provider \
console \
--auth-only