Part of DOTOBRD-359, CMM-1230

Proposed Changes

• In rebootAfterLogin, detect when the sanitized redirect URL points back to /log-in and unwrap the inner redirect_to parameter, redirecting to the actual destination directly.
• In redirectLoggedIn, extend the isExternalUrl check to allow *.wordpress.com subdomains (e.g., mysite.wordpress.com) so WoW site URLs are not rejected as external.
• Add tests for both changes (16 total across 2 test files).

Why are these changes being made?

When a passwordless user clicks their magic login link, the wp-login.php?action=magic-login API authenticates them successfully but returns a sanitized redirect_to URL that wraps the actual destination in a login page URL:

API returns: https://wordpress.com/log-in/?redirect_to=SITE/wp-login.php?action=jetpack-sso...
Instead of:  SITE/wp-login.php?action=jetpack-sso...

rebootAfterLogin then redirects to this login page URL. Since the user is passwordless, they cannot complete login at /log-in/, creating an infinite loop. This blocks all passwordless account login and new account creation (which defaults to passwordless).

Additionally, when a logged-in user lands on /log-in/?redirect_to=https://mysite.wordpress.com/..., the redirectLoggedIn middleware rejects the subdomain URL as "external" and falls back to redirecting to / instead of the user's site.

This was confirmed and the approach suggested by mmtr on DOTOBRD-359.

Testing Instructions

• The redirect-unwrapping logic can be verified via unit tests:
  • yarn test-client client/state/login/actions/test/reboot-after-login.js
  • yarn test-client client/login/test/redirect-to-login.js
• To test end-to-end: create a passwordless account, request a magic login link, click it, and verify the user is redirected to their destination rather than looping back to the login page.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2).
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

🤖 Generated with Claude Code