WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#12609 new defect (bug)

Enabling FORCE_SSL_ADMIN breaks wp-cron.php

Reported by: dphiffer Owned by: westi
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Cron API Keywords: has-patch dev-feedback
Focuses: Cc:

Description

I just completed a server migration and discovered that scheduled posting broke during the process. I tried a few things, including the suggestions from ticket #8923 with no luck. I realized that one change I made, on the new server, was a requirement that the admin uses SSL. After disabling FORCE_SSL_ADMIN I discovered that scheduled posts work again. It seems that I can leave FORCE_SSL_LOGIN turned on and it doesn't cause any problems. This is good enough for our security needs, but I'm sure others might want to have both enabled.

Attachments (2)

12609.diff (2.2 KB) - added by sivel 4 years ago.
Use wp_remote_head instead of wp_remote_post with empty body and switch default for sslverify to false
12609.2.diff (611 bytes) - added by sivel 4 years ago.
Per dd32 there are problems with some hosts where head requests are not processed properly. Just relax the ssl verification for cron requests.

Download all attachments as: .zip

Change History (11)

comment:1 johnbillion4 years ago

  • Cc johnbillion@… added

comment:2 nacin4 years ago

Relevant code:

wp_remote_post( $cron_url, array('timeout' => 0.01, 'blocking' => false, 'sslverify' => apply_filters('https_local_ssl_verify', true)) );

If you're using a self-signed or invalid cert, then sslverify=true will prevent the request. You can try this:

add_filter( 'https_local_ssl_verify', '__return_false' ); // __return_false() is 3.0

comment:3 nacin4 years ago

  • Component changed from General to HTTP
  • Owner set to dd32

comment:4 dphiffer4 years ago

  • Cc dphiffer added

comment:5 dd324 years ago

  • Component changed from HTTP to Cron
  • Owner changed from dd32 to westi

IMO, the security check should be relaxed there for cron, It should allow a loopback connection without having to verify the certificate is correct, its not like a man in the middle attack could occur here?

comment:6 dd324 years ago

  • Milestone changed from Unassigned to 3.0

sivel4 years ago

Use wp_remote_head instead of wp_remote_post with empty body and switch default for sslverify to false

comment:7 sivel4 years ago

  • Cc matt@… added
  • Keywords has-patch dev-feedback added

So nacin, Viper007Bond and myself discussed that we should switch sslverify to false as a default and keep the filter so if it is needed we can force verification.

Also we were using wp_remote_post with no body, which gets converted to a GET request and we make sure in wp-cron.php that $_POST is empty before continuing.

We may still want to look at the following logic in wp-cron.php as it seems a little strange that we are making sure $_POST is empty:

if ( !empty($_POST) || defined('DOING_AJAX') || defined('DOING_CRON') )
        die();

sivel4 years ago

Per dd32 there are problems with some hosts where head requests are not processed properly. Just relax the ssl verification for cron requests.

comment:8 nacin4 years ago

  • Milestone changed from 3.0 to 3.1

There is currently a filter in place that can fix this, this isn't a regression. Let's get this right in 3.1.

comment:9 nacin3 years ago

  • Milestone changed from Awaiting Triage to Future Release

Still needs feedback on proper course here.

Note: See TracTickets for help on using tickets.