service exits after sending 2fa notification email on startup

[bojanrajkovic]

Overview

When starting the program initially with a WebUI configured for password and MFA and an SMTP configuration is given, the service does not properly start up, instead exiting immediately after sending the notification.

I'm running icloudpd inside Kubernetes, in order to have continuous backups of my and my wife's iCloud photo libraries, and this makes it basically impossible to start icloudpd properly and have SMTP notifications.

Steps to Reproduce

1. Run icloudpd like so: icloudpd --directory "/data/photos/iCloud (Bojan)" --username <omitted> --watch-with-interval 3600 --auto-delete --align-raw original --no-progress-bar --password-provider webui --mfa-provider webui --smtp-username <omitted> --smtp-password <omitted> --smtp-host email-smtp.us-east-1.amazonaws.com --notification-email <omitted> --notification-email-from <omitted> --cookie-directory /auth
   1. The /auth directory is a persistent volume mounted into the container for it to store the session data for pyicloud.
2. Wait for the WebUI to load
3. Hit the WebUI and provide your password

Expected Behavior

1. The WebUI passes the password back to the backend
2. The backend detects that 2FA is needed
3. The backend does not send the SMTP notification because this is the initial run
4. The WebUI switches to 2FA input mode

Actual Behavior

1. The WebUI passes the password back to the backend
2. The backend detects that 2FA is needed
3. The backend sends the SMTP notification
4. The backend immediately exits

Context

I think you can work around this by turning off SMTP for the initial run, and then turning it back on, but I haven't experimented with that yet.

[AndreyNikiforov]

Good catch. smtp notification stops icloudpd without trying MFA providers. That may be a reasonable behavior for console provider, but for webui does not make a lot of sense.

[AndreyNikiforov]

Expected behavior
The backend does not send the SMTP notification because this is the initial run

Adjusting expectation: webui should support first and subsequent authentication attempts. Consequently, if smtp is configured as well, I expect notification to be sent before webui is ready to accept password/MFA code.

Reality: re-authentication is not supported yet (besides smtp+webui not working per this issue)

[bojanrajkovic]

Expected behavior
The backend does not send the SMTP notification because this is the initial run

Adjusting expectation: webui should support first and subsequent authentication attempts. Consequently, if smtp is configured as well, I expect notification to be sent before webui is ready to accept password/MFA code.

Makes sense to me, as it makes re-auth make more sense too — send the notification first, then switch to password/MFA input mode.

Reality: re-authentication is not supported yet (besides smtp+webui not working per this issue)

At least the MFA lasts for a while, so reauth can come later! :)

[AndreyNikiforov]

I hope that making webui installable in mobile phone and its supporting local notification will be reasonably easy (ideas in #805). That may be another alternative to smtp notification.

[bojanrajkovic]

I think push notifications on mobile from websites require HTTPS, which might be a bit of a challenge for some folks — you might want to look at options like Gotify or Pushover or other alternative providers.

[AndreyNikiforov]

I think push notifications on mobile from websites require HTTPS, which might be a bit of a challenge for some folks — you might want to look at options like Gotify or Pushover or other alternative providers.

My initial research suggested the same. Just need to try and see how hard it would be to setup HTTPS and, most likely, domain. Then it would be a balance of convenience of installable app and notification vs setup.

I am not familiar with other providers. If possible, I'd like to keep icloudpd as little locked on other providers as possible.

[bojan-rajkovic-simplisafe]

I think push notifications on mobile from websites require HTTPS, which might be a bit of a challenge for some folks — you might want to look at options like Gotify or Pushover or other alternative providers.

My initial research suggested the same. Just need to try and see how hard it would be to setup HTTPS and, most likely, domain. Then it would be a balance of convenience of installable app and notification vs setup.

I am not familiar with other providers. If possible, I'd like to keep icloudpd as little locked on other providers as possible.

Yeah, fair. There’s a library, https://github.com/caronc/apprise, that lets you keep it fairly decoupled, might be a good middle ground!

[bojanrajkovic]

In my original report, I said:

I think you can work around this by turning off SMTP for the initial run, and then turning it back on, but I haven't experimented with that yet.

That doesn't seem to work — I restarted with SMTP on, and my existing cookie data (confirmed that it exists in /auth, started with --cookie-directory /auth) was not used. Instead, icloudpd wants to re-authenticate from scratch again.

Is there any point to saving that data/should it be reused across restarts if it's still valid, or is re-authing every time the app restarts the expectation? If saving that data should work, I can file a separate bug.

EDIT: Never mind, I see that I had to only enter the password, but MFA was retained. :)

[holomekc]

My workaround are two different runs. One with --auth-only and smtp configured, which will inform me about expired mfa, and a dedicated run, which is used as sync without smtp config