Summary
ApplicationPasswordsManager.getApplicationCredentials(site) returns NotSupported for any site.isWPCom site. The guard is correct for Simple sites but blocks Atomic sites, which are also isWPCom-flagged and do support REST app-password creation on their direct host.
Current state
libs/fluxc/src/main/java/org/wordpress/android/fluxc/network/rest/wpapi/applicationpasswords/ApplicationPasswordsManager.kt:45:
if (site.isWPCom) return ApplicationPasswordCreationResult.NotSupported(
WPAPINetworkError(
BaseNetworkError(
GenericErrorType.UNKNOWN,
"Simple WPCom sites don't support application passwords"
)
)
)The error message says "Simple WPCom sites" but the predicate is isWPCom, which is true for Atomic too.
Why it matters
Atomic sites are full WordPress installs:
- They accept WP.com bearer auth against the direct host (the same token we already send through the WP.com proxy).
- They expose
/wp/v2/users/me/application-passwords like any other WordPress install.
For Atomic sites without an application password we already have everything needed to mint one headlessly — same code path ORIGIN_WPCOM_REST (Jetpack) uses today — except this early return blocks it. Users have to go through the Chrome Custom Tab authorize-application.php flow even though the app could create the credential on their behalf.
What to do
Relax the guard to site.isWPComSimpleSite() (or site.isWPCom && !site.isWPComAtomic). For Atomic, route through the WP.com-bearer path (jetpackApplicationPasswordsRestClient.createApplicationPassword(site) or a sibling) so the call hits the direct host with bearer auth.
Things to verify:
- The WP.com bearer is actually accepted by Atomic direct hosts on
/wp/v2/users/me/application-passwords. The proxy already routes equivalent calls, so this should work, but worth confirming with a manual probe before wiring it in.
getOrFetchUsername works for Atomic. Today it branches on ORIGIN_WPCOM_REST only — Atomic falls into the else branch and would return site.username, which may or may not be set for Atomic sites added via the WP.com login flow.- Behaviour when the app password already exists on the server with the same name (409 / CONFLICT handling already exists in
handleApplicationPasswordCreationResult).
Related
Summary
ApplicationPasswordsManager.getApplicationCredentials(site)returnsNotSupportedfor anysite.isWPComsite. The guard is correct for Simple sites but blocks Atomic sites, which are alsoisWPCom-flagged and do support REST app-password creation on their direct host.Current state
libs/fluxc/src/main/java/org/wordpress/android/fluxc/network/rest/wpapi/applicationpasswords/ApplicationPasswordsManager.kt:45:The error message says "Simple WPCom sites" but the predicate is
isWPCom, which istruefor Atomic too.Why it matters
Atomic sites are full WordPress installs:
/wp/v2/users/me/application-passwordslike any other WordPress install.For Atomic sites without an application password we already have everything needed to mint one headlessly — same code path
ORIGIN_WPCOM_REST(Jetpack) uses today — except this early return blocks it. Users have to go through the Chrome Custom Tabauthorize-application.phpflow even though the app could create the credential on their behalf.What to do
Relax the guard to
site.isWPComSimpleSite()(orsite.isWPCom && !site.isWPComAtomic). For Atomic, route through the WP.com-bearer path (jetpackApplicationPasswordsRestClient.createApplicationPassword(site)or a sibling) so the call hits the direct host with bearer auth.Things to verify:
/wp/v2/users/me/application-passwords. The proxy already routes equivalent calls, so this should work, but worth confirming with a manual probe before wiring it in.getOrFetchUsernameworks for Atomic. Today it branches onORIGIN_WPCOM_RESTonly — Atomic falls into the else branch and would returnsite.username, which may or may not be set for Atomic sites added via the WP.com login flow.handleApplicationPasswordCreationResult).Related
WpLoginClient.apiDiscovery) treats the symptom. With headless app-password creation for Atomic, the editor could consistently use the direct host with auth on Atomic sites, and capability detection could go back to a single code path.