CMM-2149: Guide WordPress.com-connected sites to WordPress.com login

[adalpari]

Description

On the "Enter your existing site address" login screen (the Application Password flow),
users whose site is hosted on WordPress.com hit a generic dead-end error. WordPress.com
sites can't use Application Passwords, so the flow fails and the user gets no hint that they
should have used "Continue with WordPress.com". This caused support ticket #11413559 (two HE
replies to resolve).

The screen already redirects literal *.wordpress.com URLs up front (WPUrlUtils.isWordPressCom),
but not WordPress.com sites on custom/mapped domains (e.g. mobile.blog), which look like any
other domain.

Approach

WpLoginClient.apiDiscovery() — which we already call to find the Application Passwords
endpoint — reports the site's authentication mechanism. WordPress.com sites advertise
OAuth2; self-hosted sites advertise ApplicationPasswords. We now read that signal instead
of assuming Application Passwords, and route WordPress.com sites straight to the WordPress.com
OAuth flow (the same destination as the existing up-front isWordPressCom check). This is how
the GutenbergKit demo app distinguishes the two, and it naturally covers custom-domain WP.com
sites without any extra network call.

Changes

• ApplicationPasswordLoginHelper: added DiscoveryResult.WpComSite; on a successful
  discovery it checks DiscoverSuccessWrapper.isWpComSite() (auth mechanism is OAuth2) and
  returns WpComSite instead of throwing on the missing Application Passwords URL.
• LoginSiteApplicationPasswordViewModel: emits a wpComDetected event for WpComSite.
• LoginSiteApplicationPasswordFragment: on wpComDetected, opens the WordPress.com OAuth
  flow directly (showWPcomLoginScreen), matching the existing static-check behavior.
• The three other DiscoveryResult consumers (My Site app-password cards, auto-auth dialog,
  app-password dialog) handle the new WpComSite branch as an unsupported/hidden case; they
  only run for already-added self-hosted sites, so it's effectively unreachable there.
• Unit tests for the OAuth2 → WpComSite mapping and the WpComSite → wpComDetected event.

Android-only; the report notes iOS likely needs the same fix separately.

Linear: CMM-2149

Testing instructions

NOTE: test the following steps in the main screen "Log in form". This is "Enter your existing site address" CTA. Do not use the "Continue with Wordpress.com" CTA.

1. Self-hosted Application Password site

   1. Log in → "Enter your existing site address".
   2. Enter a self-hosted site URL that supports Application Passwords.
   • Verify it proceeds to the Application Password authorization page (no WordPress.com redirect).

2. WordPress.com site on a .wordpress.com domain

   1. Enter a something.wordpress.com address.
   • Verify it opens the "Continue with WordPress.com" login flow.

3. WordPress.com site on a custom domain (e.g. https://mobile.blog/)

   1. Enter the custom domain.
   • Verify it opens the "Continue with WordPress.com" login flow (instead of a generic error).

Regression:

4. Enter an unreachable/invalid URL.
   • Verify the existing generic error is still shown under the field.

[dangermattic]

	1 Warning
⚠️	PR is not assigned to a milestone.

Generated by 🚫 Danger

[wpmobilebot]

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

	App Name	Jetpack Android
	Build Type	Debug
	Version	pr23106-ab6bc20
	Build Number	1498
	Application ID	com.jetpack.android.prealpha
	Commit	ab6bc20
	Installation URL	1o8vcl939o4e8

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

[wpmobilebot]

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

	App Name	WordPress Android
	Build Type	Debug
	Version	pr23106-ab6bc20
	Build Number	1498
	Application ID	org.wordpress.android.prealpha
	Commit	ab6bc20
	Installation URL	56dl3hipf4ivg

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

[codecov]

Codecov Report

❌ Patch coverage is 61.53846% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 37.63%. Comparing base (184bd2b) to head (ab6bc20).
⚠️ Report is 1 commits behind head on trunk.

Files with missing lines	Patch %	Lines
...ationpassword/ApplicationPasswordViewModelSlice.kt	0.00%	7 Missing and 1 partial ⚠️
...word/ApplicationPasswordAutoAuthDialogViewModel.kt	0.00%	3 Missing ⚠️
...tionpassword/ApplicationPasswordDialogViewModel.kt	0.00%	2 Missing and 1 partial ⚠️
...i/accounts/login/ApplicationPasswordLoginHelper.kt	95.23%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            trunk   #23106   +/-   ##
=======================================
  Coverage   37.63%   37.63%           
=======================================
  Files        2343     2343           
  Lines      127290   127316   +26     
  Branches    17655    17662    +7     
=======================================
+ Hits        47903    47920   +17     
- Misses      75464    75473    +9     
  Partials     3923     3923           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jkmassel]

One thing we should make sure is part of this – self-hosted sites can also expose oauth as an authentication mechanism via plugins, so we should double-check that the domain for the URL is .wordpress.com – otherwise someone could use it as a vector to get our client ID and secret.

[adalpari]

One thing we should make sure is part of this – self-hosted sites can also expose oauth as an authentication mechanism via plugins, so we should double-check that the domain for the URL is .wordpress.com – otherwise someone could use it as a vector to get our client ID and secret.

I see, so a self-hosted site allowing oauth will be derived to wpcom login, that's what you mean, right?
The problem is that checking if it's a .wordpress.com domain won't work if the user types a custom domain. (That was the point of the PR actually)

[adalpari]

@jkmassel I've fixed the problem by checking the oauth uthroization URL as well. WPUrlUtils.isWordPressCom(authentication.endpoints.authorizationUrl).

The fix prevents the false wpcom-positive. I don't think there was any vector leak, though.

Please give it another round.