[Bug]: Redirect destinations are not preserved after user account creation

[DavidRothstein]

Quick summary

If you visit any URL that you need to be logged in to access, it will redirect you to the login page, and if you log in from there it will nicely redirect you back to your final destination afterwards, via use of a redirect_to URL parameter.

However, if you click "Create a new account" from that login page, then after account creation you wind up thrown into the site creation flow -- the original destination in redirect_to is gone and you never get back there.

In many cases, this is a terrible user experience. Basically whatever purpose you were trying to create your WordPress.com account for, you are taken completely away from that with no obvious way back!

This issue was originally noted by me in pdtkmj-Ks-p2#comment-1231 as part of the subscription gifting project, and then moved to #70354. The fix there wound up being to use a logged-out checkout flow (which was the best user experience for that specific subscription gifting scenario anyway) but the underlying problem here seems like a major user experience problem that could be affecting many parts of WordPress.com.

---

To solve this, the "Create a new account" link probably needs to be conditionally changed to something like https://wordpress.com/start/account/user?redirect_to=[....] (i.e., put the user into the simple account creation flow that doesn't expect to send the user to site creation afterwards, and also preserve the original redirect_to parameter that was there before). This should mostly work, although basic testing showed that in some cases you might wind up with a "Building your site" interstitial inserted on the page before you are redirected.

Steps to reproduce

1. While logged out, visit any URL that requires login (example, https://wordpress.com/me/purchases).
2. Notice that you are redirected to the login page with the destination in a redirect_to parameter (example, https://wordpress.com/log-in?redirect_to=%2Fme%2Fpurchases),
3. Create an account from that page.

What you expected to happen

After creating an account, I would expect to wind up on the page I was originally trying to go to.

What actually happened

I wound up in the site creation flow, e.g. at a URL like https://wordpress.com/start/user or https://wordpress.com/start/domains.

Browser

No response

Context

No response

Platform (Simple, Atomic, or both?)

No response

Other notes

No response

Reproducibility

Consistent

Severity

None

Available workarounds?

None

Workaround details

No response

[DavidRothstein]

I put this onto the Shilling Team board for now, since I think @michaeldcain had started to look into it. But it's not actually related to payments in any specific way.

[obenland]

I just encountered that while working on a support ticket, where it breaks the flow of users signing up to get access to a private site:

Screen.Recording.2023-10-10.at.10.07.43.AM.mov

It looks like the both the create new account button and the link to request a login link don't maintain the redirect_to parameter, while the link to the app login does.

[obenland]

Bumping priority as this is currently breaking oAuth flows (or is part of broken oAuth flows).
See p1697220716421119-slack-C02T4NVL4JJ

[lsl]

I've shipped #83026. I tested as much as I could find and we've added some unit tests to make sure the behavior was mostly kept the same.

We did still alter the behavior of login urls containing a redirect_to param. So that may cause some issues to pop up. Unless there is a major issue with it we can likely fix any issues by passing in signup_flow=onboarding to the log-in url exhibiting the issue.

Logging out landing on /?apppromo login link > signups skip /start/onboarding. Didn't find any others that set a redirect_to so I don't think this is a wider issue to address. All other landing pages don't do this. One exception is /hosting which does have a redirect_to param, however, I don't think that was working properly (it needed this fix) - I tested that flow and it seemed to make sense with the change.

Testing also uncovered that we're not localizing the create site link on localized log-in pages, issue: https://github.com/Automattic/dotcom-forge/issues/4233

[allilevine]

I opened an additional follow-up, it looks like redirect destinations aren't preserved when you click to verify your email: #83182