Forum Replies Created

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter comtek

    (@comtek)

    Ok, now login works, but:
    – Authentication Groups doesn’t work: user can’t login although it belongs to the authorized group. Also the original version has this issue.

    Yeah, I never had this working either. The code looks quite specific (it requires memberOf in the user object to contain the DN of a group with a specific CN).

    A workaround would be to have a ‘Account Filter Expression’ something like “(memberOf=cn=mygroup,dc=example,dc=com)”

    – I can’t see name and mail attribute in the WP user panel, but only uid (I can see them in the original version).

    Okay, this is another bug.

    The fix is to change:
    function wpDirAuth_retrieveUserDetails($userAttribs){
    into
    function wpDirAuth_retrieveUserDetails($aryUserDetails){

    Please note that the details are only synchronised at first login, so you’ll need to delete the user.

    – Role mapping doesn’t work: I’d like to map “group1” in “editor” role with Role-map base DN: ou=groups,dc=mydomain,dc=com and Role Mapping for Editor: (cn=group1)

    (cn=group1) will always be true (assuming that group exists).

    Perhaps you want (&(cn=group1)(member=%dn)) or (&(cn=group1)(memberUid=%uid)) ? Its been a while since I wrote this, but I think one of those would work.

    Thread Starter comtek

    (@comtek)

    Okay, this forum doesn’t like my spacing. The patched file is here:

    https://plugins.trac.www.ads-software.com/raw-attachment/ticket/2190/wpDirAuth.2.php

    Thread Starter comtek

    (@comtek)

    So the error is at 473. isInDirectory is true and $isBound is false.

    Do you have a single LDAP server? If so, the only way I can see this happening is if ldap_get_dn at 465 returns true, then wpDirAuth_bindtest at 458 returns false.

    The list of warnings you give suggests that dirAuthRoleMaps was never initialized as an array. Oops. This is a bug. I wouldn’t have expected bindtest to break as a result, but still, perhaps this patch would fix the issue:

    <br />
    --- /var/www/www.dev.comtek.co.uk/wp-content/plugins/wpdirauth/wpDirAuth.php    2014-04-10 22:05:26.000000000 +0100<br />
    +++ /var/www/new.www.comtek.co.uk/wp-content/plugins/wpdirauth/wpDirAuth.php    2014-06-23 21:55:34.000000000 +0100<br />
    @@ -558,9 +558,9 @@<br />
           * @return array List of LDAP attributes<br />
           */<br />
         function wpDirAuth_attribsToLookup()<br />
         {<br />
    -        $filters=array_values(get_site_option('dirAuthRoleMaps'));<br />
    +        $filters=array_values( is_array(get_site_option('dirAuthRoleMaps')) ? get_site_option('dirAuthRoleMaps') : array() );<br />
             $attrs=array_reduce(<br />
                 array_map('wpDirAuth_attribsNeeded', $filters),<br />
                 "array_merge", array() );<br />
             $attrs=array_merge($attrs, array_values(unserialize(WPDIRAUTH_LDAP_RETURN_KEYS)), wpDirAuth_attribsNeeded(get_site_option('dirAuthRoleMapBase')) );<br />
    @@ -618,9 +618,9 @@<br />
                 $roleMapBaseDn = get_site_option('dirAuthBaseDn');<br />
             $roleMapBaseDn=wpDirAuth_substituteLDAPValues($roleMapBaseDn, $userAttribs);<br />
             $roleMapBaseDn=$roleMapBaseDn[0];</p>
    <p>-        foreach(get_site_option('dirAuthRoleMaps') as $role=>$roleFilter)<br />
    +        foreach( (is_array(get_site_option('dirAuthRoleMaps')) ? get_site_option('dirAuthRoleMaps') : array()) as $role=>$roleFilter)<br />
             {<br />
                 if(!strlen($roleFilter))<br />
                     continue;<br />
                 $expanded=wpDirAuth_substituteLDAPValues($roleFilter, $userAttribs);<br />
    @@ -746,8 +746,9 @@<br />
                 $institution      = wpDirAuth_sanitize($_POST['dirAuthInstitution']);<br />
                 $strAuthGroups    = wpDirAuth_sanitize($_POST['dirAuthGroups']);<br />
                 $strMarketingSSOID= wpDirAuth_sanitize($_POST['dirAuthMarketingSSOID']);<br />
                 $roleMapBaseDn    = wpDirAuth_sanitize($_POST['dirAuthRoleMapBase']);<br />
    +            $roleMaps=array();<br />
                 foreach($wp_roles->role_objects as $roleObject) {<br />
                     $roleName=$roleObject->name;<br />
                     $tmp=$_POST['dirAuthRoleMaps_'.$roleName];<br />
                     if($tmp)<br />
    @@ -819,9 +820,9 @@<br />
                 $strAuthGroups      = wpDirAuth_sanitize(get_site_option('dirAuthGroups'));<br />
                 $strMarketingSSOID  = wpDirAuth_sanitize(get_site_option('dirAuthMarketingSSOID'));<br />
                 //Require unsanitised data.<br />
                 $roleMapBaseDn      = get_site_option('dirAuthRoleMapBase');<br />
    -            $roleMaps           = get_site_option('dirAuthRoleMaps');<br />
    +            $roleMaps           = is_array(get_site_option('dirAuthRoleMaps')) ? get_site_option('dirAuthRoleMaps') : array();</p>
    <p>             // Have to be allowed to contain some HTML<br />
                 $loginScreenMsg  = wpDirAuth_sanitize(get_site_option('dirAuthLoginScreenMsg'), true);<br />
                 $changePassMsg   = wpDirAuth_sanitize(get_site_option('dirAuthChangePassMsg'), true);<br />
    Thread Starter comtek

    (@comtek)

    I see three possible places that message could turn up.

    Does it display “WordPress Login Error” or “Directory Authentication Error” before the “Incorrect password”?

    Was your user able to log in to 1.7.6 without the patch applied?

    What are “Account Filter Expression” and “Account Name Attribute Filter” set to?

    I’ll try to look through the code and see if I can figure out what could be wrong, but it is difficult without more information to go on.

Viewing 4 replies - 1 through 4 (of 4 total)