Did it work with v1.7.9? There is very little difference between 1.7.9 and 1.7.10. It’s mostly clean up and adding some additional checks to make sure a variable exists before using it. Also, does v1.7.10 work when you use it a normal fashion (through the log in web interface)? What error messages are you receiving?
Yes, it did work on v1.7.9, with WP 4.2.1. The WP 4.2.2 update and the v1.7.10 update came within minutes of one another, so I’m unsure of which caused what. The v1.7.10 works as expected, except for the URL calls. I can log in as directory users at multiple WP levels and as the locally created cron user through the normal GUI. However, I can not use the local account, or the directory accounts, when using the URL methods. Disable the WPDirAuth plugin, and the local cron user job runs perfectly. I’ve tried via cURL, wget, PHP, and through FireFox. All return the same “ERROR: Invalid username and/or password” message. However, the Apache ssl_access_log is returning (sanitized):
serverIPaddress – – [04/Feb/2016:20:44:32 -TZ] “GET /correct/path/wp-content/plugins/civicrm/civicrm/bin/cron.php?name=cronuser&pass=supersecretbutnofunnycharacters&key=anothersupersecretwithgoodcharacters HTTP/1.1” 200 40
192.168.254.20 – – [04/Feb/2016:20:45:02 -TZ] “POST /correct/path/wp-content/plugins/civicrm/civicrm/bin/cron.php HTTP/1.1” 200 40
As you can see, these are returning 200, which should be good returns. Disable the WPDirAuth plugin and the exact same command, seconds after disabling works great. Again from the Apache ssl_access_log (sanitized):
ClientIP – – [04/Feb/2016:20:58:29 -TZ] “GET /correct/path/wp-admin/plugins.php?deactivate=true&plugin_status=all&paged=1&s= HTTP/1.1” 200 146623
ClientIP – – [04/Feb/2016:21:00:02 -TZ] “POST /correct/path/wp-admin/admin-ajax.php HTTP/1.1” 200 47
ServerIP – – [04/Feb/2016:21:00:02 -TZ] “POST /correct/path/wp-content/plugins/civicrm/civicrm/bin/cron.php HTTP/1.1” 200 –
ServerIP – – [04/Feb/2016:20:59:00 -TZ] “GET /correct/path/wp-content/plugins/civicrm/civicrm/bin/cron.php?name=cronuser&pass=supersecretbutnofunnycharacters&key=anothersupersecretwithgoodcharacters HTTP/1.1” 200 –
All on CentOS6, PHP 5.4 from the SCL repo, Apache 2.2 from base repo. Same behavior on two different boxes with essentially the same setup.
Also, I can’t find any activity on other logs. Error and ssl_error show nothing.
Any chance you can put v1.7.9 of wpDirAuth on your v4.2.2 of wordpress and see if it works or fails? I want to rule out that it isn’t a change in wordpress between v4.2.1 and v4.2.2 in combination with wpDirAuth.
Here is a diff of wpDirAuth between v1.7.9 and v1.7.10
https://www.diffchecker.com/zooqpj25
(you can ignore the @version 1.7.8 on the left side. that was an oversight. correct version is listed at line 66)
All referenced line numbers are from the left side.
As you can see, there isn’t a whole lot that changed. At line 511, there was a possibility that $results had not been set. Line 513 then threw a notice in that situation. So I set a default for it to false. I then adjusted wpDirAuth_retrieveUserDetails at line 1483 to have $rscResults default to false, and changed 1486 to check for bool false instead of null.
Line 1203 I removed the require_once on registration.php since that file has been deprecated since v3.1 of wordpress and was no longer needed.
Line 1235 I changed split to explode since split was deprecated in PHP v5.3.0 and has been removed in PHP v7.0.0
Lines 2104-6 were debugging lines that i commented out as they shouldn’t have been left in there.
removed line 2276 as it isnt needed.
Besides changing the version numbers, that’s it. I can’t see anything that would cause it to work with 1.7.9 but fail with 1.7.10.
Good call. 1.7.9 is exhibiting the same behavior now. Must be a change with WP 4.2.1 to 4.2.2. Sorry. Next try?
Just FYI, saw this in FireBug, working on something completely unrelated, but thought it might be of interest:
{“wp-auth-check”:true,”server_time”:1454689592}
{“wp-auth-check”:true,”server_time”:1454689652}
{“wp-auth-check”:true,”server_time”:1454689712}
{“wp-auth-check”:true,”server_time”:1454689772}
{“wp-auth-check”:true,”server_time”:1454689832}
{“wp-auth-check”:true,”server_time”:1454689892}
As you can see, there is a 60 count interval in the time stamp. As I have a cron task configured to fire once a minute, I’d assume that those intervals are seconds.
Just to clarify: you said you’re on wordpress v4.2.2, but was released back in May 2015. Do you mean v4.4.2?
If you’re on 4.4.2, I’m not seeing anything relating to login functionality: https://codex.ww.wp.xz.cn/Version_4.4.2
I downloaded civiccrm. They call wp_authenticate twice in the file civicrm/CRM/Utils/System/Wordpress.php at lines 305 and 427. At line 427, they’ve made an incorrect assumption. wp_authenticate returns either a user object, or an instance of WP_Error. It will never return false. Lines 428-433 will never happen. Also, at line 421, if they include pluggable.php and wpDirAuth hasn’t loaded yet, wpDirAuth will be unable to handle wp_authenticate. in fact, given what I’m looking at in their code, I’m surprised you’re not seeing a PHP error about not being able to redeclare wp_authenticate. Plugins should never load pluggable.php directly.
Yes, 4.4.2. Sorry, typo. Too many version numbers this week. Interesting find on CiviCRM. I’ll point the devs towards what you have found. So, are you saying that this is a CiviCRM error that is just now showing up?
Again, thanks for taking the time to look at this. I’ve filed a bug in CiviCRM at:
https://issues.civicrm.org/jira/browse/CRM-17981
I’ve commented all of the lines listed out and I get exactly the same results.
Sorry, I should say that I’ve commented all the 400 lines out, so 421 and 427-437.
Yes, 4.4.2. Sorry, typo. Too many version numbers this week.
TOTALLY understand.
are you saying that this is a CiviCRM error that is just now showing up?
Not necessarily. I’m not familiar with the civicrm plugin and what it is supposed to do. Just in looking at their code I see two potential issues. Now, those same two issues should have been present with wordpress 4.4.1, so why things stopped working at v4.4.2, I have no idea. I do know one of things they fixed in 4.4.2 was a SSRF issue, and they’ve been pretty tight-lipped on where the issue was and how they corrected it.
Well, that type of vulnerability would fit the bill. Weird that it would still be allowed through the built in login, but fail when a third-party plugin was allowed. How long are these types of issue kept under wraps? I know many projects seem to have set an arbitrary two weeks before disclosure.
one other thing you could try is to set
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);
in your wp-config.php file, try authenticating via the URL again, and then check the contents of /wp-content/debug.log to see if there are any clues there as to why things arent working correctly
[05-Feb-2016 15:45:47 TZ] PHP Notice: Object of class WP_Error could not be converted to int in /correct/path/wp-includes/pluggable.php on line 32
[05-Feb-2016 15:45:47 TZ] PHP Notice: Undefined property: WP_Error::$ID in /correct/path/wp-includes/class-wp-user.php on line 165
[05-Feb-2016 15:45:47 TZ] PHP Notice: Undefined property: WP_Error::$ID in /correct/path/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php on line 444
So, line 444 could be a culprit, but looks like it’s a problem stemming from line 165, all of which comes from trying to run pluggable.php directly and missing WPDirAuth’s services?
