BasicAuth prevents WP Cron & scheduled actions from running

[thenbrent]

trafficstars

Describe the bug

Not so much a bug, but something I see as an improvement to reduce support load.

For more context, see: #2362020-zen

To reproduce

1. Enable HTTP Basic Authentication for your site. Do not allow unauthenticated internal requests.
2. Watch as renewals don't happen as would be expected.

Screenshots

Expected behavior

For subscriptions to do some kind of check against this and output useful information to the site owner explaining how they can solve this problem and remove the step that requires them to contact us to get an explanation.

---

Props @WillBrubaker for the report originally posted at https://github.com/woocommerce/woocommerce-subscriptions/issues/3464

[thenbrent]

To address this, we could do something similar to #91 and proactively check if HTTP loopback requests are blocked and notify the admin, with information on how to fix it.

I'm 98% sure this issue will affect the new aysnc runner as well as the default WP Cron runner.

[jfarsen]

Hi. I can confirm this problem still exists and affects any notifications from WooCommerce, Subscriptions and AutomateWoo.

We use HTTP Basic Auth to ensure nothing (human, bots) can spider a site while in DEV.

From the comments here, do I get the sense that you're wanting to notify the admin of the problem, but that it still won't be technically possible to perform Scheduled Actions when HTTP Basic Auth is present?

[WillBrubaker]

Heya @jfarsen I'm not an expert on configuring BasicAuth, but I believe it is possible to configure it such that local requests can bypass authentication. https://cwiki.apache.org/confluence/display/HTTPD/BypassAuthenticationOrAuthorizationRequirements

[rrennick]

Another alternative that might work if you have people logged into the dashboard is Alternate CRON

but that it still won't be technically possible to perform Scheduled Actions

You can manually run actions from the Scheduled Actions admin screen.

[crstauf]

Possible the CLI runner works behind HTTP authentication, which has the advantage of processing all actions rather than individual actions one at a time.

[barryhughes]

It would seem this must also impact WP Cron—when spawned asynchronously via HTTP requests—and in essence is not an Action Scheduler-specific problem (also worth noting, in a case where WP Cron is running, that should ensure some movement happens in relation to scheduled actions).

I'm going to go ahead and close, though if anyone feels strongly that we need a solution baked into Action Scheduler, do feel free to comment or open a fresh issue.