Wordpress-ios: Login: cannot sign in to a WordPress.com Business site using the site address login flow

[designsimply]

Steps to reproduce:

1. Start by entering the username and password of a WordPress.com Business site (Atomic) into a password manager or anywhere you can copy paste from so you can verify you are entering the same username and password every time.
2. Go to "Log" In and select the option to enter your site address.
3. Enter the address of an Atomic site and tap "Next".
4. Copy and paste the username and password and tap "Next".
5. Observe that an error appears and does not let you move forward.
6. Go to http://wordpress.com/log-in in Safari.
7. Copy and paste the same username and password to log in.
8. Observe that logging in on the web with the same username and password works normally.

Result: logging in to a WordPress.com Business site (Atomic) site using the site address flow does not work, an error appears that says the username/password isn't associated with the site but that's not true. (2m39s)

It looks like this username/password isn't associated with this site.

^{Tested with WP Internal 14.6.0.20200410 MS App Center alpha on iPhone 6S iOS 13.3.1.}

[rachelmcr]

This is also mentioned in the second case in https://github.com/wordpress-mobile/WordPress-iOS/issues/7586. (The issue mentions WordPress.com Business — I think that was before we started calling them Atomic sites.)

[designsimply]

Adding a quick noted to say that Atomic sites were never fully supported in Authenticator-iOS and it would likely take significant time to add support for that so this issue may not be suitable for a Groundskeeping rotation—but we can send it through at the next cycle to get a confirmation. 👍

^{(internal reference: p5T066-1fv-p2#comment-4733)}

[elibud]

@mattmiklic curious to hear your thoughts about this one, is this a flow worth adding under the unified sign in project?

[mattmiklic]

It sounds like the issue is when a user enters the "site address" flow, then tries to use their WordPress.com username and password to log in.

Could we address this with a flow that goes something like this?

1. User enters site address
2. We check to see if WordPress.com login is enabled on the site
3. If so, we redirect them to the WordPress.com login flow
4. If not, we proceed with step 2 of the site address flow

cc @mindgraffiti

[mindgraffiti]

@renanferrari @mattmiklic @elibud

tl;dr: No, I do not plan on adding this to UL&S.

AFAIK, Atomic sites were never supported in the Site Address flow. Last time I looked into this (groundskeeping), an API call was missing, a loginFields bool needed changed, and an XML-RPC error would need an override.

This time when I checked it out, I also checked Android. Android follows the same behavior. If it gets changed for iOS, we'll need to change it on Android as well. Android doesn't have this enhancement filed yet. Tested on Google Pixel 2 with WordPress 14.9 using Android 10.

Since AT sites can already log in using the WP.com email flow, I would classify this as "nice to have" but not necessary. Estimated time to implement is 2 weeks with 1 dev, because new UI would need added and the business logic needs altered. Unknown for Android because their framework is markedly different from iOS.

If we're interested in increasing our number of successful logins, I would want to fix the integrated accounts flow in stuck in an endless loop first. Ref. pbArwn-su-p2

[mindgraffiti]

@frosty this is too big for Groundskeeping but I think it would be a good fit for the XML-RPC error improvement project.

[renanferrari]

Thanks for pinging me here @mindgraffiti. I agree that this is out of scope for the UL&S project.

[elibud]

I think there should be an easier solution to implement the flow that @mattmiklic is suggesting:

We check to see if WordPress.com login is enabled on the site

We must have an endpoint that we can hit with a site address to check if the site is hosted in WordPress.com, and if we don't it must be fairly easy to add one.

Since AT sites can already log in using the WP.com email flow

This is correct, but please note that what @mattmiklic suggests is not adding a new flow, but redirecting to the existing WordPress.com login flow once we detect the site is hosted on WordPress.com.

[mattmiklic]

Here's a visual of the flow, in case it helps clarify what I was suggesting:

It might require tweaking the wording a bit on the "Get Started" screen when it's encountered via this flow, since we know that a WordPress.com account already exists for the site.

[mindgraffiti]

Our atomic site users make up 0.002% of our active users. That number of users won't increase our impact for our login goals.

I know the flow looks simple on the surface, but the business logic and code isn't. I still stand by the sprint estimate and I disagree this flow needs added to UL&S.

[elibud]

Whether a site is atomic or not is unrelated to the issue, what we are proposing here would help any WordPress.com user that's trying to login with their site address instead of their username/email credentials.

We are not asking for an increase in the project scope, thus delaying the original ETA, but instead that this new flow is considered as an enhancement once the core flows are completed.

[mindgraffiti]

We are not asking for an increase in the project scope, thus delaying the original ETA, but instead that this new flow is considered as an enhancement once the core flows are completed.

Ok. We could do core flows first, ship it, then this one. @renanferrari what do you think?

[frosty]

Ok. We could do core flows first, ship it, then this one.

I agree that we should tackle this flow, but I don't think it should disrupt progress on the currently scoped US&L project.

This would be nice to fix, but not urgent – business site users can log in using email address, which is the primary way we intend for WordPress.com users to log in anyway. Non-atomic WordPress.com users can currently log in using site address if they like (but again, we push towards email address primarily).

So, I think this should be a future enhancement which we can certainly add to our backlog – it would probably make sense to tackle after the rest of US&L is complete, so we don't have any conflicts or duplicated work. Although @mindgraffiti do you think it would work if somebody else were to work on the new API request while US&L continues?

[frosty]

Forgot to say, @mattmiklic thanks for the design input here!

[mindgraffiti]

@frosty I don't think there is an API request any more. @elibud is right, the site info response returns a isWPCom bool, so we know if a site is hosted by WP.com. And yes, thank you @mattmiklic. Re-using the screen from the new UI would speed up development.

[ScoutHarris]

Fixed with https://github.com/wordpress-mobile/WordPress-iOS/pull/14908.