No Cron job if incorrect authentication ?

Hi Eugene, can you let me know how you are testing whether cron is able to access? I need to be able to see whatever it is that you are seeing, so that I can take a closer look. As far as I understand it, cron requests — like all other requests — are allowed only if/when you are authenticated (e.g., via the plugin settings), which I think makes sense unless I am missing something here.

• This reply was modified 3 years, 5 months ago by Jeff Starr.

Hi Jeff,

I am checking Apache SSL/TLS Logs in Plesk CP and if there was a correct authentication by site visitor (so far just me testing) then I can see Cron jobs being executed with the return code 200, e.g.:
“POST /wp-cron.php?doing_wp_cron=1625112734.6077289581298828125000 HTTP/1.0″ 200 …”

But if authentication failed (or Cron set to regular date/time execution) then Cron is triggered, but fails with the return code 401, e.g.:
“POST /wp-cron.php?doing_wp_cron=1625093881.6393480300903320312500 HTTP/1.0″ 401 …”

Maybe it is intended behaviour, but then my concern is what if there is no correct authentication for days or weeks (we intend to use the site only on rare occasions as a cloud repository), so Cron jobs are not executed for a long time ?

Of course we can set the company rule for some authorized person to enter the site every now and then, therefore triggering proper Cron execution, but it does not feel as a nice/robust strategy.

Regards,
Eugene

• This reply was modified 3 years, 5 months ago by eugene212.

Okay thanks for the infos. Let me ask this, are you protecting the entire WP site with HTTP auth? Or just some specific directory?

I am protecting the entire website which happens to be a WP site.

So yeah, then even if the plugin were to allow unauthenticated cron requests, they would not happen unless/until you (or some other user) logged in and was authenticated. WP Cron requires a visit to your site in order to run.

Possibly I was not clear enough when describing my observations – when talking about authentication I did not mean logging into WP, rather providing credentials (username and password) for password protected site (standard option in Plesk), i.e. anyone visiting the site will see a popup window where they need to enter correct username and password to be able to see the site.

In other words, I did not refer to logging as a WP user, rather any attempt to visit the site – Cron jobs are triggered, but give error 401 if incorrect credentials were used.

So my expectation was that the Cron jobs would be done if/when regular bots, etc. try to get to the site.

Alternative approach which I have tried was to use the periodic task (e.g. every hour) to execute wp-cron – again, the logs show that Cron is triggered in due time, but gets 401 code.

I’m not sure if I understand, but I will investigate further and see if there is anything that can be done to accommodate the scenario you’re describing.

Thanks Jeff, appreciate your prompt responses and effort.

The bottom line in my scenario is to have Cron jobs properly executed when there is any attempt to visit the password protected site regardless of entered (or skipped) credentials, i.e. to operate similar to non-password protected sites.

Currently Cron is triggered when expected, but gets 401 code for its HTTP request if a visitor (bot, etc.) did not use correct credentials.

Alternative approach which I have tried was to use the periodic task (e.g. every hour) to execute wp-cron – again, the logs show that Cron is triggered in due time, but gets 401 code.

Looks like that it was my incorrect observation (probably I have misinterpreted some logs), so I set it up now as a regular OS Cron task instead of WP Cron triggered on site visits – it seems to be a recommended practice anyway and suits my case very well.

Thanks again for your prompt responses !

It’s all good. I’m glad you found a solution, Eugene. I’ll look closer at this when it’s time for plugin updates (soon), just to see if there is any way to accommodate what you’re describing above. Thank you and take care.