Gutenframe: Logging in and out as different users interferes with redirects [8]

[kwight]

In testing Gutenframe attempts to handle logged out users on the Jetpack side, a few edge cases were discovered that should be addressed.

This tests really well now, with both Atomic and Jetpack sites, and admin and non-admin users (also SSO and without). I was able to find a particular test user of mine that always hits a server (not WP) 401 on a certain v1 Atomic site; however, the same user works on other Atomic sites, and other users work on that Atomic site, so I have no explanation of what edge-case I'm hitting, or if it's an issue non-a11s will see in production. Considering the positive testing of everything else, I wouldn't want it to be a blocker.

I also found an edge case that causes the user to hit this wall:

If a user:

• is logged in as user A,
• loads the block editor, successfully setting the auth cookies on the Jetpack site,
• then logs out of WordPress.com,
• and back into WordPress.com as user B,
• then loads the same JP site's block editor again,
• the existing cookies for the Jetpack site will be for user A (triggering the mismatch).

See https://github.com/Automattic/jetpack/pull/12215 for details.

[obenland]

I was able to reproduce it with the steps outlined in https://github.com/Automattic/jetpack/pull/12215#pullrequestreview-236058316. I wonder if this could be fixed in Jetpack's and WP.com's Jetpack_SSO::build_sso(_login)_url() by passing the frame-nonce argument back and forth.

I just don't know how to test it without proxy-ing the API 🙂

But that's why it's failing, we don't have a frame nonce to verify.