UFMatch to contact in wrong domain, ignoring CIVICRM_UNIQ_EMAIL_PER_SITE

[davej]

Hi,

Found a Drupal user persistently being UF-matched to a contact from another domain, even after deleting the offending uf_match entry. Tracked it down to CRM_Core_BAO_UFMatch::synchronizeUFMatch.

When $_POST is not empty, synchronizeUFMatch calls CRM_Dedupe_Finder to find matches. This ignores domain, parent groups and CIVICRM_UNIQ_EMAIL_PER_SITE. :-(

When $_POST is empty, synchronizeUFMatch calls CRM_Contact_BAO_Contact::matchContactOnEmail, which respects CIVICRM_UNIQ_EMAIL_PER_SITE.

So when you log in as a user with no uf_match entry, $_POST contains your username & password from the login form, so CRM_Dedupe_Finder is called and domain and CIVICRM_UNIQ_EMAIL_PER_SITE are ignored. This results in our user being matched to a contact from another domain and so getting access to custom groups that they shouldn't.

Dave J

[davej]

Another multi-site UFMatch problem:

When first setting up a new site under a multi-org installation, initially the only Drupal user will be uid 1. So as this user, you create a new Drupal user. This fires civicrm.module's civicrm_user, which calls the UFMatch code, with the permissions of uid 1. The UFMatch code takes the dedupe route rather than the CRM_Contact_BAO_Contact::matchContactOnEmail route, because $_POST is not empty. So even once the dedupe code is changed to respect ACLs, because here it's operating as uid 1, it will match against all domains and ignore CIVICRM_UNIQ_EMAIL_PER_SITE, as described in the original post.

So the newly created user will be matched to an existing contact in another domain if one exists. This contact will then be a member of both sites' parent groups.

Dave J

[Deepak Srivastava]

So if we assume that dedupe respects ACLs (as fixed for 3.1.4) the problems that exist are -
1. User created by admin is matched with all the domains.
2. Dedupe ignoring CIVICRM_UNIQ_EMAIL_PER_SITE flag and always doing match for the logged-in domain (not considering #1).

#2 is a minor, but if we want to make CIVICRM_UNIQ_EMAIL_PER_SITE flag consistent, we could either fix dedupe to respect it -OR- remove CIVICRM_UNIQ_EMAIL_PER_SITE flag and make synchronize() always look for a match in logged-in domain for multi-site environment.

#1 sounds like a bug. Will need to discuss / research (as i'm not sure if its a trivial fix).

[davej]

Hi Deepak,

Thanks for your comments. I'm not certain but I believe it worked correctly before CRM_Core_BAO_UFMatch::synchronizeUFMatch was changed to use different execution paths depending on whether $_POST is empty. I mean this code, around line 210:

Code: [Select]

            if ( ! empty( $_POST ) ) {
                $params = $_POST;
                $params['email'] = $uniqId;

                require_once 'CRM/Dedupe/Finder.php';
                $dedupeParams = CRM_Dedupe_Finder::formatParams ( $params      , 'Individual' );
                $ids          = CRM_Dedupe_Finder::dupesByParams( $dedupeParams, 'Individual' );
               
                if ( ! empty( $ids ) ) {
                    $dao = new CRM_Core_DAO( );
                    $dao->contact_id = $ids[0];
                }
            } else {
                require_once 'CRM/Contact/BAO/Contact.php';
                if ( $uf == 'Standalone' ) {
                    $dao =& CRM_Contact_BAO_Contact::matchContactOnOpenId( $uniqId, $ctype );
                } else {
                    $dao =& CRM_Contact_BAO_Contact::matchContactOnEmail( $uniqId, $ctype );
                }
            }

I believe the else clause ($_POST empty) does the right thing: CRM_Contact_BAO_Contact::matchContactOnEmail checks CIVICRM_UNIQ_EMAIL_PER_SITE and if set, it restricts the search to contacts in CRM_Core_BAO_Domain::getChildGroupIds.

So I'm wondering if the solution to all the problems mentioned above is to use the CRM_Contact_BAO_Contact::matchContactOnEmail route rather than the CRM_Dedupe_Finder route for the cases we're discussing. However I don't know the context or intention of the above code, there's probably a good reason why it is as it is. Just had a dig around, seems to be rev 24219 for CRM-5104 (Add ACL Support for CiviReports, Autocomplete contact search widget, and Full-text search).

Dave J

[Deepak Srivastava]

We need to fix UFMatch dedupe code to respect CIVICRM_UNIQ_EMAIL_PER_SITE. Filed an issue here - http://issues.civicrm.org/jira/browse/CRM-6083.

[petednz]

Does this perhaps relate to the issue i just spotted whereby I have two civicrm contacts with the same drupal account?

[Deepak Srivastava]

Does this perhaps relate to the issue i just spotted whereby I have two civicrm contacts with the same drupal account?

Does the two contacts belong to different domain ? If yes thats an intended behaviour with CIVICRM_UNIQ_EMAIL_PER_SITE set.
Otherwise if you could let us know hows / when that happening, i could fix it with same issue.

[davej]

See http://issues.civicrm.org/jira/browse/CRM-6083

Dave J