Notify of connection issue due to blog ID change and offer fix when possible

[dechov]

If there is a change in blog ID (i.e. Jetpack_Options::get_option( 'id' )), and especially if there is no longer a blog ID present, it would be good to notify the merchant. We could detect this by caching it and comparing.

There was messaging added in #1912 (by @marcinbot, fixing #1804) but it only appears if is_server_connected() – we may want to generalize this to cases where the connection is completely severed, except that we don't show that overview page task list unless WCPay is connected, so we'll have to expose something on the Setup screen (and possibly elsewhere).

In addition, if there is a blog ID but it is different from the one previously used on that site with WCPay, it might be good to also offer to re-link the original Stripe account, replacing the old blog ID with the new one (requiring a server change to re-link Stripe accounts between WPCOM sites with the same owner).

(Previously discussed a bit in p1626072282287000/1625774522.237500-slack-CGGCLBN58.)

It would be nice to track the occurrence / usage of this notification, if possible.

EDIT by @daquinons: According to this message, the scope of the issue is:

spotting blog ID mismatch and adding notification as part of this issue.

Part of the issue will be to split this one and to create a new issue for addressing the second part:

In addition, if there is a blog ID but it is different from the one previously used on that site with WCPay, it might be good to also offer to re-link the original Stripe account, replacing the old blog ID with the new one (requiring a server change to re-link Stripe accounts between WPCOM sites with the same owner).

which might be possible to be fixed using the Safe Mode?

[dechov]

See also #830 – we should consider to what extent it makes sense to solve that broader issue at the same time or with the same implementation.

[asumaran]

@dechov I can’t reproduce Scenario 1 from here paJDYF-1Ss-p2. I’ve tried it multiple times. Jetpack enters in Safe mode in the second site only.

This issue if I'm not mistaken tries to fix the problem where the original site enters in Safe mode (IDC) because another site has taken the blog ID from the original site. But in my tests the original site was never compromised. Second site enters in Safe mode which I think there's no problem with that.

It would be nice to find the exact steps to reproduce the identity crisis scenario on the original site otherwise I'm not sure how to address this issue.

[asumaran]

@dechov I've been trying to fix this, and I think it goes beyond my understanding and capabilities to offer a robust fix for now. Especially from the WCPay perspective.

Although I understand the problem better now (after countless attempts to provoke a Jetpack IDC), I still think I may need help to confirm the approach I've been thinking of to address this issue.

After chatting about this issue with Val, the following idea came up: Maybe we could "fingerprint" the original installation. We could create an encoded string based on the original URL (and probably the original WPCOM user) and save it on Jetpack as metadata on WPCOM.

I'm proposing this approach because, usually, the user has complete access to the DB. And when they export the DB and import it from another site, the URL is changed to fit the new host/domain, and as far I can tell, it isn't enough to rely on the site URL as it changes on Jetpack very often when duplicating sites.

If the original URL is persisted on WPCOM (without allowing it to change), we will have a reliable reference to the original site. Then if another site tries to "borrow" the Jetpack connection, we shouldn't allow it because URLs don't match.

So, if the site URL doesn't match the one in WPCOM, then we don't allow the user to reuse the WCPay/Stripe account. In that case, we ask the user to "Restore connection" which allows the user to create a new Stripe account.

Does this make sense to you? Not sure if a similar mechanism is already in place for this.

[jessy-p]

With the latest Jetpack changes and other fixes for IDC, @marcinbot Does this issue still need to be worked on?

[marcinbot]

With the latest Jetpack changes and other fixes for IDC, @marcinbot Does this issue still need to be worked on?

I will defer to @dechov but IMO we could consider it complete now that we have the IDC notice.

[dechov]

I believe the issue still stands – I have been taking a new look at IDC cases this past week and considering how this factors in, but I think this is complementary to the IDC notice. I'm pretty sure there are potential tricky cases where the blog ID is changing irrespective of the merchant's intentions – on the backend, or even on the site itself due to incoming migration – in which case either the IDC notice might not appear or "transferring the connection" back isn't an obvious solution.

[vbelolapotkov]

@dechov I'm a bit concerned with the unclear scope of this issue, especially in offering a fix. I'd suggest to focus on spotting blog ID mismatch and adding notification as part of this issue.

We could discuss offering fix part on p2 with product team and create spearate issue(s) for it.

[dmallory42]

@dechov I'm a bit concerned with the unclear scope of this issue, especially in offering a fix. I'd suggest to focus on spotting blog ID mismatch and adding notification as part of this issue.

Follow up question on this for @dechov / @marcinbot - would this be a case of showing the same messaging added in #1912 in this case? Or would we need to handle it differently? Specifically, I'm wondering whether in the case where there's a blog ID mismatch whether the Payments Overview page which that notification appears on would appear at all, or if the user would see something else like the onboarding screen?

Do you happen to know how I could reproduce a case of a blog ID mismatch locally? I could start looking into this issue but I'm concerned about not having enough context/knowledge of IDC's so it would be super helpful to have a starting point. Thanks!

[marcinbot]

would this be a case of showing the same messaging added in #1912 in this case?

Probably not, reconnecting won't fix the blog IDs. Fixing such a scenario will be a huge can of worms, if even securely possible from the client side.

Do you happen to know how I could reproduce a case of a blog ID mismatch locally?

I think @dechov looked into this quite a lot, so he might be able to provide actual reproduction steps. For the local env, we could tweak some IDs in the server's account table.

There's another question of detecting this situation, where options were floated to compare blog IDs coming from the server, or stored by Jetpack to the values cached on the site. I think that would be the most reliable way, especially considering the constraints of the local environment.