Allow headless application-password creation on Atomic sites#22885
Draft
jkmassel wants to merge 3 commits into
Draft
Allow headless application-password creation on Atomic sites#22885jkmassel wants to merge 3 commits into
jkmassel wants to merge 3 commits into
Conversation
The early-return in `ApplicationPasswordsManager.getApplicationCredentials` guarded on `site.isWPCom`, which also matches Atomic. Narrow the guard to `site.isWPComSimpleSite` so Atomic flows through the existing Jetpack-tunnel path that Jetpack-WPCom-REST sites already use. Fixes #22884
Collaborator
Generated by 🚫 Danger |
Contributor
|
|
Contributor
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## trunk #22885 +/- ##
=======================================
Coverage 37.31% 37.32%
=======================================
Files 2319 2319
Lines 124559 124559
Branches 16921 16921
=======================================
+ Hits 46484 46489 +5
+ Misses 74319 74315 -4
+ Partials 3756 3755 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Before the "Authenticate using Application Password" card is shown on My Site, attempt headless creation via the new `SiteStore.createApplicationPassword(site)` (which routes through the existing Jetpack tunnel and persists credentials onto the SiteModel so `siteHasBadCredentials` flips). On Created/Existing we hide the card; on NotSupported/Failure we fall back to today's discovery + Custom Tab prompt. This makes the Atomic guard relaxation actually user-visible — Atomic users no longer see the card or have to authorize through a browser.
The WordPress/Jetpack app had never bound a `@ApplicationPasswordsClientId`
in its Dagger graph, so any call into `ApplicationPasswordsStore` would
throw NoSuchElementException. This was latent — no production caller
hit the path on this app — until the new
`SiteStore.createApplicationPassword` started routing My Site through it
and crashed the app on launch.
- Provide `@ApplicationPasswordsClientId` from a new
`ApplicationPasswordsClientIdModule`, using the same device-interpolated
app name the Custom Tab flow already passes through `app_name`
("Jetpack Android App on <device>" / "WordPress Android App on …").
- Short-circuit `SiteStore.createApplicationPassword` to NotSupported
when the configuration is disabled, so we degrade gracefully rather
than crash if the binding is ever absent again.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes #22884.
Problem
ApplicationPasswordsManager.getApplicationCredentialsreturnedNotSupportedfor anysite.isWPComsite. The guard was correct for Simple sites but blocked Atomic sites, which are alsoisWPCom-flagged and do support REST application-password creation. The user-visible symptom: Atomic users were shown the "Authenticate using Application Password" card on My Site and had to authorize through a Chrome Custom Tab even though the app could mint the credential on their behalf.What changed
Two commits:
Relax the guard (
ApplicationPasswordsManager.kt:45):site.isWPCom→site.isWPComSimpleSite. Atomic sites now fall through to the existingorigin == ORIGIN_WPCOM_RESTbranches and useJetpackApplicationPasswordsRestClient— the same path Jetpack-WPCom-REST sites use today, routed through the WP.com proxy.Auto-mint before showing the card (
ApplicationPasswordViewModelSlice.buildApplicationPasswordDiscovery): before the card is rendered, attempt headless creation via a newSiteStore.createApplicationPassword(site). OnCreated/Existingwe persist credentials onto the SiteModel (sositeHasBadCredentialsflips false) and skip the card. OnNotSupported/Failurewe fall back to today's discovery + Custom Tab card.The new
SiteStore.createApplicationPasswordmirrors the existingdeleteApplicationPasswordshape and is the public entry point —ApplicationPasswordsManageritself staysinternalto fluxc.Site type coverage
Tests
FluxC manager:
given a simple WPCom site, when we ask for a password, then return NotSupportedgiven an Atomic site, when we ask for a password, then create it via the Jetpack clientViewModel slice:
given headless mint succeeds, then hide card and skip discoverygiven headless mint returns NotSupported, then fall back to discoveryWhat we explored
public-api.wordpress.com, which already handles Atomic. Direct-host calls on Atomic are the Editor fails to load on Atomic sites when theme-styles capability over-reports availability #22879 follow-up.wpApiRestUrlfrom a freshwpLoginClient.apiDiscoveryagainst the Atomic URL during auto-mint. Deferred — the card-hide condition only checksapiRestUsernamePlain/Password, and the Editor fails to load on Atomic sites when theme-styles capability over-reports availability #22879 follow-up will need to setwpApiRestUrlanyway when it routes auth-aware calls to the direct host.Testing instructions
Atomic happy path:
android-jetpack-client-<device>(or the WordPress equivalent) exists in the site's wp-admin → Users → Profile → Application Passwords.A_P:and confirmHiding card for <url> - headless mint succeeded.Simple WPCom regression:
bad discoveryfallback.Self-hosted regression:
Related