fix: open redirect_to URL in browser to prevent infinite deep link loop#22648
fix: open redirect_to URL in browser to prevent infinite deep link loop#22648
Conversation
When a tracking URL's redirect_to target can't be handled in-app, open the extracted redirect_to URL in the browser instead of the original tracking URL. This prevents an infinite loop caused by the app's intent filter re-intercepting its own public-api.wordpress.com/bar/ URLs.
|
|
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## trunk #22648 +/- ##
=======================================
Coverage 38.11% 38.11%
=======================================
Files 2263 2263
Lines 115857 115862 +5
Branches 16100 16102 +2
=======================================
+ Hits 44157 44162 +5
Misses 68075 68075
Partials 3625 3625 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
When a tracking URL's redirect_to target can't be handled in-app, the app now opens the redirect destination in the browser (loop fix) but the server never sees the original tracking URL. Fire the pixel explicitly in this path so email link taps are still recorded. The no-redirect fallback still opens /bar/ in the browser, which handles tracking implicitly via the browser's HTTP request.
|
|
I pushed a change, so we'll need to await a new prototype build before testing again. |
adalpari
left a comment
adalpari
left a comment
There was a problem hiding this comment.
Thank you for the fix! LGTM and works as expected!
Ops, just saw this. Is the new prototype ready? |
|
Noting that I tested a few different emails. All showcased the loop in trunk; all were addressed by this change.
|
@adalpari it's been ready for a while (~2 hours), so likely not an issue. The only way to confirm is to navigate to Me → About Jetpack in the installed app and verifying the version commit/build number matches the latest in #22648 (comment). |
4 participants
Description
Fix CMM-1230. Fix NL-473.
When the Jetpack app receives a
public-api.wordpress.com/bar/or/mbar/tracking URL (e.g. from a WordPress passwordless login email), it extracts theredirect_toparameter and tries to handle the destination in-app. If no handler exists for the destination (e.g.wordpress.com/log-in/link/usefor passwordless login), the fallback opens the original tracking URL in the browser.This causes an infinite loop on Play Store builds. The exact interception mechanism is unclear — the app's intent filter uses
pathPattern="/bar/.*"which shouldn't match/bar/with no trailing path segment, and local debug builds don't reproduce the issue. It may be related to Android App Links verification behaving differently for Play Store installs, or the server-side 302 redirect from/barto/bar/interacting with the verified domain. Regardless, the app repeatedly cycles between trying to handle the URL and falling back to the browser.This PR changes the fallback in
buildNavigateAction()so that when a tracking URL'sredirect_totarget can't be handled in-app, it opens the extracted redirect_to URL in the browser instead of the original tracking URL. This breaks the loop because the redirect destination (e.g.wordpress.com/log-in/link/use) is not matched by any of the app's intent filters.When there is no
redirect_toparameter at all, the existing behavior (open tracking URL withbarpath in browser) is preserved.Testing instructions
Passwordless login flow: