[REST API] Initial support for WPCom account creation during Jetpack setup

[hichamboushaba]

Closes: #14420
Closes: #14419

ℹ️ This is my first PR dealing with library updates, please let me know if I'm doing something wrong.

Description

This PR adds initial support for creating accounts during the Jetpack setup, it's based on the changes of:

• WordPressKit: Add support for sending magic links to inexistent accounts wordpress-mobile/WordPressKit-iOS#822
• WordPressAuthenticator: Add support for requesting account creation when sending auth magic link wordpress-mobile/WordPressAuthenticator-iOS#861

⚠️ Please don't merge until both PRs above are merged and the Podfile is updated.

With the above changes, we can now follow the same approach as the Jetpack web UI, if we detect that an account doesn't exist yet, we start the signup using a magic link, and when the user taps on it, they will then be automatically authenticated and they can continue the Jetpack setup.

The changes are behind a feature flag until we update the UI of the magic link screen with more clarifications about the signup flow.

Steps to reproduce

1. Sign in to a site using Application passwords.
2. Start Jetpack setup from the dashboard or app settings.
3. Enter an email that's not registered yet on WordPress.com

Testing information

• Confirm the above starts the magic link flow.
• Tap on the link in the email in your phone (or copy paste it from desktop to safari on your phone), and confirm the Jetpack setup is started after the authentication.

Screenshots

Simulator.Screen.Recording.-.iPhone.16.-.2024-11-15.at.09.45.51.mp4

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on all devices (phone/tablet) and no regressions are added.

[dangermattic]

	1 Warning
⚠️	This PR is assigned to the milestone 21.2. This milestone is due in less than 2 days. Please make sure to get it merged by then or assign it to a milestone with a later deadline.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS
	Build Number	pr14431-8f5e0d6
	Version	21.1
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	8f5e0d6
	App Center Build	WooCommerce - Prototype Builds #11698

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[hafizrahman]

Testing notes:

I was able to follow the steps in the test site and have a magic link sent to my account, with subject "Create WordPress.com account on your mobile device".

I checked log and also confirmed the "unknown_user" error:

⛔️ Error checking for passwordless account: endpointError(WordPressKit.WordPressComRestApiEndpointError(code: WordPressKit.WordPressComRestApiErrorCode, response: nil, apiErrorCode: Optional("unknown_user"), apiErrorMessage: Optional("User does not exist."), apiErrorData: nil, additionalUserInfo: Optional([:])))

I then copied the link from the email and pasted in Safari, and was given the steps to enter my site, install and connect Jetpack. Video below:

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2024-11-18.at.14.43.18.mp4

Something that's different from your video, though, is that I'm asked to enter my site address again, while on your site it automatically jumps into the "Connecting Jetpack" screen. On my test site Jetpack was not installed yet, could this be the cause?

[hafizrahman]

Not specifically related to functionality of this PR: I feel it might be valuable to add tracking for this case. What do you think?

[hichamboushaba]

Yes, it's already planned, I'll add some tracking before releasing the feature.

[hafizrahman]

wdyt about replacing the if-else with guard?

guard allowAccountCreation,
      let apiError = error as? WordPressAPIError<WordPressComRestApiEndpointError>,
      case .endpointError(let endpointError) = apiError,
      endpointError.apiErrorCode == Constants.unknownUserErrorCode else {
    analytics.track(event: .JetpackSetup.loginFlow(step: .emailAddress, failure: error))
    onError(error.localizedDescription)
    return
}

await requestAuthenticationLink(email: email, forAccountCreation: true)

I think guard helps with early return pattern and communicates what conditions are required, and reduces nesting a bit.

[hichamboushaba]

Applied in 99ad008

[hafizrahman]

The code in this PR imo is pretty straightforward and looks good to go. I left some code and testing comments to discuss.

[hichamboushaba]

Thanks @hafizrahman for the review.

Something that's different from your video, though, is that I'm asked to enter my site address again, while on your site it automatically jumps into the "Connecting Jetpack" screen. On my test site Jetpack was not installed yet, could this be the cause?

Nice find, this seems to be a bug with magic link handling for Application Passwords in general, the same issue happens also when signing in to an existing account.
From my testing, this seems to happen only if the WooCommerce app was closed before opening Safari, if the app was kept open in the background, the issue doesn't occur, can you please confirm if this was your experience too?

Assuming it's the same case for you too, then the cause is here, we don't start the handling if the defaultSite property is not set yet, from my understanding on the iOS logic, this property is not set in iOS until we fetch the site info, which could take a while, so we fallback to the default magic link handling which is for WordPress.com signing, and which shows the site picker for your case.

Since this is an existing issue, and that we can consider an edge case (because generally the user will launch the email client from the app and won't use Safari for the magic link), I'll create a bug report, and then we can proceed with merging the PR, WDYT?

[hafizrahman]

From my testing, this seems to happen only if the WooCommerce app was closed before opening Safari, if the app was kept open in the background, the issue doesn't occur, can you please confirm if this was your experience too?

I believe I just pressed the home button, then went to Safari, then pasted there. But when I retried again just now, it is not happening again:

Simulator.Screen.Recording.-.Hafiz.iPhone.15.-.2024-11-19.at.18.51.14.mp4

So perhaps in my first test, it got closed automatically.

Since this is an existing issue, and that we can consider an edge case (because generally the user will launch the email client from the app and won't use Safari for the magic link),

Yeah, this is an edge case I agree, and even then it's not a broken path because there's still a way to complete. So it's OK to be handled separately.

[hichamboushaba]

Thanks @hafizrahman, is there anything left before approving this PR?

[hafizrahman]

Pre-approving because it should be good now, however since I see additional commits, let me know if there's anything new I should be checking/testing @hichamboushaba

[hichamboushaba]

Thanks @hafizrahman actually there are no new changes, I just accidentally pushed some new commits, and after removing them, the PR was stuck in "Processing updates" state, hopefully pushing the new library changes will fix the issue before we merge this.

[mokagio]

@hichamboushaba @hafizrahman I updated the pods to point to the latest WordPressAuthenticator commit on trunk.

Notice that the Danger error about pointing to a branch is gone as a result.

This should be good to merge now, at least as far as the pods setup is concerned. Let me know if you have any questions.