WordPress MU

I am currently looking to use test a few off line blog editors with a pilot installation of WordPress MU that I installed for my current employer.

At this point in time I am trying to connect BlogJet, w.blogger and BlogDesk to the WordPress MU installation via the xmlrpc.php.

All three editors are currently giving me a bad login/pass combination error when I try to login with one of the LDAP IDs. I can however use xmlrpc if I use the WordPress MU admin account.

Is it possible to use MU/LDAP and still use an offline editor?

Current Setup -

WordPress MU 1.3
LDAP Authentication Plugin 1.2.0

w.blogger 4.02.0197
BlogJet 2.0.0.10

Any help would be most appreciated.

I have roughly the same set up, although after I couldn't get an LDAP plugin working I wrote a quick one of my own.

2 things I found. First, make sure that xml-rpc is enabled on the blog(s) you want to post on, do this via (Site Admin->Blogs->Edit).

Second, xmlrpc.php doesn't use any overridden authentication, it simply checks the given user name and password against the user name and password in its user table. Therefore, it needs hacked a bit. There are 2 options. Either, posting a link to the LDAP plugin your using so that I can say what you need to change, or have a look in ~/wp-includes/user.php , the function user_pass_ok and alter it to resemble the authentication used in the plugin.

Thanks for the response, it is encouraging to know that someone at least has this working. I am currently using the version 1.3 of the WPMU LDAP plugin located here - http://sourceforge.net/projects/wpmu-ldap/.

Any further assistance you can provide is most appreciated.

Please keep in mind that this may not work straight off and may need some tweaking, however, this should be pretty close.

This is assuming that the LDAP settings you have specified in "Site Admin" are correct and that the plugin is working. In ~/wp-includes/user.php edit the function user_pass_ok (you may wish to take a backup of the original version) to read as follows:

function user_pass_ok($user_login, $user_pass) {
    global $cache_userdata;
    $ldapServerAddr    = get_site_option("ldapServerAddr");

    $ldapServerOU      = get_site_option("ldapServerOU");

    $ldapServerCN      = get_site_option("ldapServerCN");

    $ldapServerPass    = get_site_option("ldapServerPass");

    $ldapServerPort    = get_site_option("ldapServerPort");

    $ldapEnableSSL     = get_site_option("ldapEnableSSL");
    $ldapString        = "$ldapServerAddr:$ldapServerOU:$ldapServerCN:$ldapServerPass:$ldapServerPort:$ldapEnableSSL";
    $server = new LDAP_ro($ldapString);
    if($server->Authenticate($user_login,$user_pass, null) == 0)
        return true;
    return false;
}

You will also need to add the following to the top of the same file:

include_once(ABSPATH . "wp-content/mu-plugins/ldap/lib/ldap_ro.php");

Or replace with the correct path for your install of the plugin.

Hope that helps.

Thanks for posting the code to get this working. I was able to finally authenticate against xmlrpc with BlogJet. I just wanted to let you know that I hit one snag and was wondering what was happening.

When taking the code as is, I get an error about not being able to pass variable 3 in line 34. In my user.php file this is refering to the null value being passed by the if statement. I am not sure why this value is in the string, but after removing it I no longer receive the error.

Is the null value needed? If so, any idea why I would be getting that error?

You were getting that error because I messed up, I basically skimmed over the plugin source to get the code that would just authenticate which is why I said it might not be perfect :P.

Passing a variable that is set to null as opposed to just passing in null should fix that problem. It _should_ require the third parameter set to actually work.

$user_data = null;
if($server->Authenticate($user_login,$user_pass, $user_data) == 0)...

However, if you've got it working then I expect you don't need to worry about it.

Hi,

Could you post the code in full. Would really help here with same problem.

Thanks

So, in ~/wp-includes/user.php replace the function user_pass_ok with the following:

include_once( ABSPATH . "wp-content/mu-plugins/ldap/lib/ldap_ro.php" );
function user_pass_ok($user_login, $user_pass) {
    $ldapServerAddr    = get_site_option("ldapServerAddr");

    $ldapServerOU      = get_site_option("ldapServerOU");

    $ldapServerCN      = get_site_option("ldapServerCN");

    $ldapServerPass    = get_site_option("ldapServerPass");

    $ldapServerPort    = get_site_option("ldapServerPort");

    $ldapEnableSSL     = get_site_option("ldapEnableSSL");
    $ldapString        = "$ldapServerAddr:$ldapServerOU:$ldapServerCN:$ldapServerPass:$ldapServerPort:$ldapEnableSSL";
    $server = new LDAP_ro($ldapString);
    $user_data = null;
    if($server->Authenticate($user_login,$user_pass, $user_data) == 0)
        return true;
    return false;
}

That _should_ work.

Is there a will to make the auth mechanism pluggable? Or there's already a way, but just unnoticed?

JanBrasna makes a good point. No, as far as I know there is no pluggable function for this at the moment (but I could have missed it), however, wp_login is pluggable....

According to the code comments user_pass_ok is only used in xmlrpc.php so by editing one line in the function login_pass_ok (xmlrpc.php) we get the same functionality for less work.

function login_pass_ok($user_login, $user_pass) {
if (!wp_login($user_login, $user_pass)) {
$this->error = new IXR_Error(403, __('Bad login/pass combination.'));
return false;
}
return true;
}

Perhaps that should be passed back upstream? Making this change means user_pass_ok can be removed from user.php entirely, and when a blog is XML-RPC enabled no files would need changed, it will automatically use the current authentication method whether its the default WP auth, LDAP or anything else that overrides wp_login.

That sounds good. Can anyone from the devs confirm that it's okay so that it could be submitted as a patch?

you'll have to submit it as a patch first and see if donncha will take it. That's the faastest way, I think.

Will look into it in the morning.

Actually the same applies to plain vanilla WP, see http://trac.wordpress.org/browser/trunk/wp-includes/user.php#L16 - it might be better to submit it for WP trunk and have it then re-applied to WPMU from there.

Opinions?

agreed.

have submitted a patch into wordpress trac.

Do we know when to expect the fix to be in the upstream MU code?