Jetpack: WordPress.com block editor: cannot log in with JP 8.1.1.

[jeherve]

This is a regression introduced by #14349. cc @mmtr

Steps to reproduce the issue

1. Start with a site with no SSL certificate, running the most recent version of master, including #14349
2. Log out
3. Clear your cookies for that site.
4. Try to log back in; you'll see that auth cookies cannot be created, and you consequently cannot log in.

[mmtr]

Maybe related to the fact that SameSite=None cookies only work when they are secure.

I guess that should be fixable if we return the default SameSite attribute (the one passed in the filter) if the site doesn't have a SSL cert rather than always overriding it to None:

```php
public function set_samesite_auth_cookie( $samesite ) {
return is_ssl() ? 'None' : $samesite;
}

[jeherve]

@mmtr That makes sense, and that change does allow me to log in.

Could you help me test and review #14394 so we can get this fixed for everyone?

[jeherve]

Noting that we have a few users reporting issues with 8.1.1 in the support forums:

• https://wordpress.org/support/topic/bug-8-1-1/
• https://wordpress.org/support/topic/cant-login-only-if-deactivate-jetpack-2/
• https://wordpress.org/support/topic/cant-login-only-if-deactivate-jetpack/

I'm trying to find out more about this.

[mmtr]

Just found a minor mistake on our code, not sure if it could be related to the reports.

When generating the logged in cookies, we're using the secure_auth_cookie filter to determine if cookies are secure:

https://github.com/Automattic/jetpack/blob/6ac061cd660b0632a3dbe204ef1b42163e374227/modules/wpcom-block-editor/class-jetpack-wpcom-block-editor.php#L501

But we should use secure_logged_in_cookie:

https://core.trac.wordpress.org/browser/tags/5.3/src/wp-includes/pluggable.php#L869

Alternatively, if we confirm that clearing cookies solves most of the issues, can we maybe do that programmatically if the user has updated to 8.1.X and the cross-sites cookies have not been created yet?

[jeherve]

if we confirm that clearing cookies solves most of the issues, can we maybe do that programmatically if the user has updated to 8.1.X and the cross-sites cookies have not been created yet?

Yes, that would seem like a good idea. Unfortunately, only one person confirmed that this fixed things so far.

[KokkieH]

A new report in https://wordpress.org/support/topic/cant-login-to-control-panel-jetpack-8-1-1/. I've asked them for the information @jeherve requested in the other threads.

[mmtr]

I'm starting to think that reported issues might be caused by Jetpack disabling the default auth cookies on sites where there are active plugins relying on the send_auth_cookies filter.

I wonder if it might be safer to change our approach back to a wp_set_auth_cookie override (https://github.com/Automattic/jetpack/pull/14349).

cc @jeherve @zinigor

[jeherve]

@mmtr Is there a way we could test this on one of those sites, or reproduce on a local site?

[mmtr]

Unfortunately I couldn't reproduce the issue yet, my previous comment was just a guess. We should find a plugin that relies on what the send_auth_cookies filter returns, and activate in a test site to see if Jetpack affects the login behavior.

[annezazu]

2666587-zen affected.
Previous information here: https://wordpress.org/support/topic/cant-login-only-if-deactivate-jetpack-2/

Unclear what further testing should be done @jeherve

[jeherve]

@annezazu At this point it may be useful to get a list of plugins active on those sites, so we can find a plugin that is maybe common to all those sites so we can eventually reproduce and find a fix.

Thank you!

[jeherve]

Related discussion: p1580764602411500-slack-jetpack-crew

[annezazu]

2674797-zen

jetpack Version 8.1.1
Browser Firefox 72.0.2 (64-bit) and Edge 44.18
Incognito window = Still loops/redirect
WordPress 5.3.2
My site use HTTPS
I have clean cookies in both Browser.
I have tried turning on and off all my other plugins in various combination with
Jetpack, and it seems to be Jetpack that makes it loop/redirect back to the
login screen. No matter if other plugins are active or not.
When deactive plugins in phpmyadmin the login works again.

@jeherve this occurs without any plugins on this site :/

[annezazu]

2670598-zen

Does the same problem persist on these sites if you update Jetpack when all other plugins are deactivated and you're using a default theme, like Twenty Nineteen? Yes. After deactivating all plugins except for Jetpack 8.1.1, switching the theme to Twenty Twenty and then logging out, the same login problem occurred.

Asking follow-up questions as well. This is happening on the same host across 5 sites.

[kwight]

Will be sure to look at this tomorrow.

[jeherve]

@annezazu Any chance to check if there is any mu-plugin installed on each one of those sites by the host, maybe, or anything about cookies in their wp-config.php files?

[annezazu]

2663731-zen

User tried disabling all other plugins except Jetpack with a new browser (tried multiple browsers).

I cannot enter on the dashboard, and I have . ZERO warning from the wp-admin page, it loads the login page another. Tore-enter on the dashboard, I have as usual to manually rename the jetpack plugin directory via ftp, and then I can login and see the
dashboard.

Also tied doing this with a standard theme yet the problem persists. Following up with some of the same questions from above just in case.

[kwight]

Did some testing myself, can't for the life of me get a broken state. All testing was what appears to be a common problem configuration: incognito Chrome, latest WP, Jetpack 8.1.1, HTTPS – also threw in Canary (with Same Site blocking), and tried out PHP 5.6... everything works.

IT makes me wonder if they all have a handful of specific hosts involved; they often mention it's "all my clients/sites". Is that info part of followup when they submit a request through the form they're told to fill out?

I'm also a little curious about our scope. I noticed we aren't limiting the samesite changes to just the WP.com block editor; @mmtr I can't remember, is that because there are other known Jetpack applications needing those changes, or did we apply it to everything as an oversight?

[kwight]

T makes me wonder if they all have a handful of specific hosts involved; they often mention it's "all my clients/sites". Is that info part of followup when they submit a request through the form they're told to fill out?

Ah, JP debugging tools can make an educated guess, looking at the above Zendesk ticket.

[kwight]

Re: 2663731-zen, noting that WP is a subdirectory install, and has no SSL cert.

[kwight]

This comment is interesting, implying that she is having problems without even being connected to WP.com. From what I can tell, none of the cookie manipulation we have going on would be loaded if not connected to WP.com.

Hm, if the user is referencing this site (based on their username), it is also a subdirectory install.

[kwight]

This thread is also a subdirectory install: https://wordpress.org/support/topic/cant-login-to-control-panel-jetpack-8-1-1/

[kwight]

Couldn't find any issues with a subdirectory multisite (JN) test install. 🤔

[mmtr]

@mmtr I can't remember, is that because there are other known Jetpack applications needing those changes, or did we apply it to everything as an oversight?

That's intended, since we need to customize the auth cookies created during login and that happens before the user accesses the block editor.

[KokkieH]

We've had a new report in https://wordpress.org/support/topic/no-login-possible-into-staging-site-with-jetpack-8-1-1/ which seems to indicate this is only happening on staging sites for them. I've asked them to confirm that, and to send more details via the support contact form.

[KokkieH]

Another in https://wordpress.org/support/topic/jetpack-login-issues-2/

This user uses the WPS Hide Login plugin to change the default URL of the login page.

[jenhooks]

Another in 2688747-zen

Details:

• Browsers: Chrome, Safari
• Browsers up to date? Yes to both
• Result in incognito window? Same
• Attempted in different browser? I only use the two
• WP version? Latest - 5.3(.2?)
• http or https? https
• Does clearing cookies help? No.

[RCowles]

2666587-zen affected.
Previous information here: https://wordpress.org/support/topic/cant-login-only-if-deactivate-jetpack-2/

The user in this ticket provided us with the following list of plugins as installed and active:

• Classic Editor
• Gravity Forms
• Health Check & Troubleshooting
• Smart Slider 3 Pro
• Strong Testimonials

[brucea8c]

Another report in 2691210-zen

This user reports that the issue is happening on over 5 sites that they manage. They've ended up deleting Jetpack off all sites except for one site. WordPress is installed in a subdirectory on this site.

According to the site Report Card these were the plugins active on the last sync:

• advanced-sidebar-menu/advanced-sidebar-menu
• duplicate-page/duplicatepage
• duplicator/duplicator
• gdpr-cookie-compliance/moove-gdpr  
• jetpack/jetpack
• js_composer_salient/js_composer  
• pages-in-widgets/pagesinwidgets
• really-simple-ssl/rlrsssl-really-simple-ssl  
• safe-svg/safe-svg
• simple-membership/simple-wp-membership
• stops-core-theme-and-plugin-updates/main 
• wordpress-seo/wp-seo
• yotuwp-easy-youtube-embed/yotuwp
   

[bindlegirl]

One of the users from the forum jasubal contacted us in the ticket with these replies:

1- it happens in every browser (SAFARI/CHROME/EXPLORER…)
2- incognito window same problem
3- incognito different browsers same problem
4- doesn’t work. I can’t log in
5- WP Current Version: 5.3.2
6- All Our Websites are OVER HTTPS
7- We tried to clear all cookies but same problem happens

zd-2691239

[csonnek]

Update on 2663731-zen - replies from the user to our questions

• Is any mu-plugin installed on this sites by your host?

Nope, no mu-plugin installed at all (if "mu-plugin" refers to "must use" plugin in the "plugins" directory, I have no a "mu-plugin" directory in all the site)

Is there anything about cookies in your wp-config.php file?

Nothing too here. I checked the wp-config.php file here, and apparently there is nothing about cookies.

[mdbitz]

Hi everyone:

8.2 beta contains a few more cookie patches. We're having trouble duplicating the behavior our users are experiencing. @annezazu is following up with 2663731-zen to test the beta to see if it resolves the issue.

If other users reporting the issue appear to be technically inclined we can request they try the following steps

1. remove the current jetpack plugin out of the "plugins" folder
2. install the beta version from https://downloads.wordpress.org/plugin/jetpack.8.2-beta2.zip
3. See if they can login clear cookies and then successfully login
4. Let us know the results
5. if still an issue delete the beta version of the plugin and put their current version back

Check the zendesk ticket for wording as Anne is an expert in communication.

[annezazu]

Going to follow up with 2663731-zen too after seeing their reply :)

[annezazu]

Update from 2663731-zen @mdbitz - sadly this didn't work:

I tried the beta prosed as fix (the "8.2-beta", of course cleaning in
advance cookies and cache, tried too with other machines and browsers),
and installed the .zip. *_But sadly the problem persist as always_: no
warning at all, and I can login ONLY if the directory created "jetpack"
is renamed (as with the V.8.1.x).

The strange thing about, it's that I have this issue with the Jetpack
plugin, ONLY with one site, the other one is working correctly, and they
have the same WP version, same hosting server, about the same plugins
set, theme and configuration.

[kwight]

ONLY with one site

Is one a subdirectory install, and the other not? That's one detail that keeps cropping up when I check various reports (haven't gone through all of them , mind you 🙃 )

[annezazu]

@kwight the person in 2663731-zen took note of your response and wanted to offer some more context (they don't have a github account):

yes it's a subdirectory install (named /wp1). But the other
installation of WP that I have in the same shared server (also with
Jetpack active, about same plugins set, same theme), it is too in a
subdirectory, but it's not affected by this issue with Jetpack 8.1.x.

[annezazu]

2687043-zen

Getting info from them now.

[bikedorkjon]

2683260-zen requesting info

[annezazu]

2685465-zen requesting more info to confirm. For now:

Please understand that I had copied my wordpress site that was in the root directory to a subfolder and then pointed my domain to see the subfolder as the root.
Is there something in the wordpress local database that is caching the login if Jetpack is enabled?
I have also cleared out my browser history.

Did not mean to close out this issue. I hit some sort of browser shortcut mid typing. Apologies.

[mdbitz]

looks like we implemented the false !== check in the argument vs on the function call, ooops

[gaurav1984]

2678124-zen

Details

• Using Latest Chrome
• Issue happening with FF too
• WP 5.3.2 installed
• site is using HTTPS
• WP installed in a subfolder
• Issue not happening on 2nd site which is installed on the same server with WordPress installed in the root folder for the site.