Answers.Body: <p>I'd try to run CiviCRM cron via the CLI. If your webhosting has CLI access, you can do this using <a href="http://wp-cli.org/" rel="nofollow noreferrer"><code>wp-cli</code></a> or <a href="https://github.com/civicrm/cv" rel="nofollow noreferrer"><code>cv</code></a>. Both will let you execute CiviCRM's scheduled jobs. See <a href="https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/#command-line-syntax-for-running-jobs" rel="nofollow noreferrer">Managing Scheduled Jobs > Command Line Syntax</a> for setup instructions.</p>
  
  <p>I can't say why you're running into issues, and I don't know why you'd have started having issues at the upgrade of 4.7.27 - that's worth looking into (and could be worth debugging - you'd start by checking the input variables are correct when that error is thrown in <a href="https://github.com/civicrm/civicrm-core/blob/d440ff56b20209ece52dc70d775d75af44fff05a/CRM/Utils/System.php#L578" rel="nofollow noreferrer"><code>CRM_Utils_System::authenticateScript()</code></a>).</p>
  
  <p>It <em>could</em> be that <a href="http://www.pluginmirror.com/plugins/wordfence/" rel="nofollow noreferrer">WordFence</a> is playing a part in this. CiviCRM's URL cron method involves putting the username and password into GET parameters, which isn't generally a recommended practice (those details can be leaked from GET, see <a href="https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/#running-command-line-scripts-via-url" rel="nofollow noreferrer">note here</a>). It wouldn't surprise me if WordFence detected and removed sensitive variables in GET params; another possibility is that WordFence might block a user if it detected them logging in every few minutes (as could be happening with URL cron). This is speculation; I don't know WordFence at all.</p>
  
  <p>If CLI cron is available to you, that approach might mitigate this situation, and would at least avoid the possibility of leaking your CiviCRM scheduled job user credentials. It's not a guaranteed fix and I do recommend a shot at debugging what's actually happening, especially if it means resolving some new bug that's sneaked into 4.7.27!</p>
  
  <p>(This isn't a very certain answer, but I hope it helps!)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-11T05:16:21.213Z
Answers.Text: Thanks for your comprehensive reply! I would love to work at debugging it, but I really don't know what I'm doing and this is a production web site, so... However, I installed wp-cli, set up the cron job to call it, and everything seems to work as expected. I can see that this is a much cleaner way to do it, but of course I have to have full access to my system (which I do, on a Linode, but I would not have had in the past).
Answers.UserDisplayName: SJNorton
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-11T05:17:47.923Z
Answers.Text: So, it's working, but the original mystery remains unsolved. If someone could help me with the steps to do that, I'd be interested in debugging it at a less busy time. Thanks, all!
Answers.UserDisplayName: SJNorton
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-11T05:23:49.870Z
Answers.Text: By the way: I had Wordfence running before this all came up, but I upgraded it to the paid (premium) version at basically the same time I updated CiviCRM. I suppose a first test would be to disable it and try the URL method again.
Answers.UserDisplayName: SJNorton
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-11T11:14:57.690Z
Answers.Text: Maybe WordFence has logging somewhere, that says what it intercepted? Let us know how you get along!
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-11T02:33:03.263Z
Answers.LastActivityDate: 2017-11-11T02:33:03.263Z
Answers.UserDisplayName: Chris Burgess
Body: <p>I've got a puzzle. After updating to CiviCRM 4.7.27 (from 4.7.23) on WordPress, suddenly the civicrm cron jobs stopped being run. With some digging, I found that the credentials for the user I had set up to run cron were being rejected ("ERROR: Invalid username and/or password").</p>
  
  <p>I confirmed that the username, password and site key were all correct (none of them had changed), but I still can't get it to work. I even created a new user with a new password, but that also failed. Both users have the correct permissions to access CiviCRM, etc. as specified in the documentation. I am even able to log in directly to WP using these credentials; they are only rejected in the context of a call to run cron.php.</p>
  
  <p>I use the URL method of calling cron.php, which includes the username, password and site key in the full URL.</p>
  
  <p>This isn't critical - I can still run it manually from inside CiviCRM, but I have already spent a lot of time on this and don't want to spend much more.</p>
  
  <p>CiviCRM 4.7.27<br>
  WordPress 4.8.3, with WordFence 6.3.21, all plugins up-to-date<br>
  CentOS 7, with the standard PHP 5.4.16 as supplied by the main CentOS repositories</p>
  
  <p>Thanks in advance!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-10T21:35:56.973Z
Comments.Text: Could you have a look at the Troubleshooting section in https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/ and permissions for cli.php and cron.php.  You may need to change permissions to 744 to allow execution in /wp-content/plugins/civicrm/civicrm/bin/cli.php and cron.php.  I have to do this after every update of civicrm in wordpress.  Hope this helps.
Comments.UserDisplayName: peterb
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-11T00:08:23.043Z
Comments.Text: If the error message is "ERROR: Invalid username and/or password" then `cron.php` is executing so it can't be filesystem permissions?
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-11T04:43:27.530Z
Comments.Text: Thanks for the suggestion: permissions for /wp-content/plugins/civicrm/civicrm/bin are 775, and for both cli.php and cron.php they are 664. It's unusual to give write access to the group, but at least that should mean the user has access. I thought the executable bit was only for directories? Anyway, setting it for cron.php didn't change anything, sadly.
Comments.UserDisplayName: SJNorton
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-20T18:42:48.710Z
Comments.Text: Did you manage to track down the cause? [Another person reported very similar problems with WP/Civi today.](https://chat.civicrm.org/civicrm/pl/ooitrkezmjn4xden8z3ww5kkqa)
Comments.UserDisplayName: Chris Burgess
Tags: <wordpress><error><cron>
Title: CiviCRM cron user rejected after update to 4.7.27
ThreadText: # CiviCRM cron user rejected after update to 4.7.27
  
  (Asked by: username_0 on 2017-11-10)
  
  I've got a puzzle. After updating to CiviCRM 4.7.27 (from 4.7.23) on WordPress, suddenly the civicrm cron jobs stopped being run. With some digging, I found that the credentials for the user I had set up to run cron were being rejected ("ERROR: Invalid username and/or password").
  
  I confirmed that the username, password and site key were all correct (none of them had changed), but I still can't get it to work. I even created a new user with a new password, but that also failed. Both users have the correct permissions to access CiviCRM, etc. as specified in the documentation. I am even able to log in directly to WP using these credentials; they are only rejected in the context of a call to run cron.php.
  
  I use the URL method of calling cron.php, which includes the username, password and site key in the full URL.
  
  This isn't critical - I can still run it manually from inside CiviCRM, but I have already spent a lot of time on this and don't want to spend much more.
  
  CiviCRM 4.7.27  
  WordPress 4.8.3, with WordFence 6.3.21, all plugins up-to-date  
  CentOS 7, with the standard PHP 5.4.16 as supplied by the main CentOS repositories
  
  Thanks in advance!
  
  **Tags:** wordpress, error, cron
  
  > **Comments:**
  > **username_1**: Could you have a look at the Troubleshooting section in https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/ and permissions for cli.php and cron.php.  You may need to change permissions to 744 to allow execution in /wp-content/plugins/civicrm/civicrm/bin/cli.php and cron.php.  I have to do this after every update of civicrm in wordpress.  Hope this helps.  
  > **username_2**: If the error message is "ERROR: Invalid username and/or password" then `cron.php` is executing so it can't be filesystem permissions?  
  > **username_0**: Thanks for the suggestion: permissions for /wp-content/plugins/civicrm/civicrm/bin are 775, and for both cli.php and cron.php they are 664. It's unusual to give write access to the group, but at least that should mean the user has access. I thought the executable bit was only for directories? Anyway, setting it for cron.php didn't change anything, sadly.  
  > **username_2**: Did you manage to track down the cause? [Another person reported very similar problems with WP/Civi today.](https://chat.civicrm.org/civicrm/pl/ooitrkezmjn4xden8z3ww5kkqa)  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-11-11. Score: 0 | Accepted answer
  
  I'd try to run CiviCRM cron via the CLI. If your webhosting has CLI access, you can do this using [`wp-cli`](http://wp-cli.org/) or [`cv`](https://github.com/civicrm/cv). Both will let you execute CiviCRM's scheduled jobs. See [Managing Scheduled Jobs > Command Line Syntax](https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/#command-line-syntax-for-running-jobs) for setup instructions.
  
  I can't say why you're running into issues, and I don't know why you'd have started having issues at the upgrade of 4.7.27 - that's worth looking into (and could be worth debugging - you'd start by checking the input variables are correct when that error is thrown in [`CRM_Utils_System::authenticateScript()`](https://github.com/civicrm/civicrm-core/blob/d440ff56b20209ece52dc70d775d75af44fff05a/CRM/Utils/System.php#L578)).
  
  It *could* be that [WordFence](http://www.pluginmirror.com/plugins/wordfence/) is playing a part in this. CiviCRM's URL cron method involves putting the username and password into GET parameters, which isn't generally a recommended practice (those details can be leaked from GET, see [note here](https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/#running-command-line-scripts-via-url)). It wouldn't surprise me if WordFence detected and removed sensitive variables in GET params; another possibility is that WordFence might block a user if it detected them logging in every few minutes (as could be happening with URL cron). This is speculation; I don't know WordFence at all.
  
  If CLI cron is available to you, that approach might mitigate this situation, and would at least avoid the possibility of leaking your CiviCRM scheduled job user credentials. It's not a guaranteed fix and I do recommend a shot at debugging what's actually happening, especially if it means resolving some new bug that's sneaked into 4.7.27!
  
  (This isn't a very certain answer, but I hope it helps!)
  
  > **Comments:**
  > **username_0**: Thanks for your comprehensive reply! I would love to work at debugging it, but I really don't know what I'm doing and this is a production web site, so... However, I installed wp-cli, set up the cron job to call it, and everything seems to work as expected. I can see that this is a much cleaner way to do it, but of course I have to have full access to my system (which I do, on a Linode, but I would not have had in the past).  
  > **username_0**: So, it's working, but the original mystery remains unsolved. If someone could help me with the steps to do that, I'd be interested in debugging it at a less busy time. Thanks, all!  
  > **username_0**: By the way: I had Wordfence running before this all came up, but I upgraded it to the paid (premium) version at basically the same time I updated CiviCRM. I suppose a first test would be to disable it and try the URL method again.  
  > **username_2**: Maybe WordFence has logging somewhere, that says what it intercepted? Let us know how you get along!  
  
  ---
  
  