CiviCRM Community Forums (archive)

I've upgraded successfully to CiviCRM 3.0 on Joomla 1.5, but have just discovered that it appears to break the Joomla Civicrm Authentication plugin. Any Joomla user who is not a Super Administrator is treated as not having a valid membership and sent to the expired membership page. Super Administrators can login with no problems.

The only way round this I've found is to disable the plugins, but that then allows people to lign whose membership really has expired.

Has this problem been reported already and is there any workaround?

Thanks

ian

OK, will do

Hi Ian,

I wrote this plugin ages ago and have been using it successfully ever since. I too recently went from 2.x to 3.0 and it is working for me. I know in the past there have been issues with the uf_match borking if a user changed their email address but now updating email from profiles works correctly in CiviCRM.

I'm not a coder by trade and don't have much time to get on these things. Do you know if there is an updated API we should be using?

Henry

Hi Ian,

I'm Super Admin but have a "registered" account too just for testing. I can see members logging in fine so figure it must be working. Thanks for the heads up on the fix. Understand that it is quick and dirty but if it works thats cool.

When I get some time (or anyone else?) I'll look into the APIs and make sure I've got the latest versions. While the ones I'm using are V2 they aren't listed as depreciated (I think).

Henry

This fix works for me too :-)

I didn't notice the problem at first as I was testing with an administrator account. When testing as a registered user after upgrading from 2.2.7 to 3.0.2, I was unable to log in whether my status was new, current or grace.

Adding $contactID = $contactID+0; to line 128 of /plugins/authentication/civicrm.php as you suggest fixed it.

Thanks! Much appreciated.

Nic

It's in the function "civicrm_membership_contact_get"  in civicrm/api/v2/MembershipContact.php. Line 138 tests the value of the passed parameter to see if it's an integer (in which case it's recognised as the legacy case where a contactID is passed from the compatibility wrapper).
line 138:
} elseif( is_integer($params) ) {
The contactID that the civicrm authentication plugin passes ($SontactID) is cast as a string and so fails the is_integer test (though it would return true in if test with is_numeric()). Adding 0 to the contact ID  froces it to betyped as an integer and so it then passes the test.

In the authentication plugin the contact ID is obtained on line 124:
$contactID = CRM_Core_BAO_UFMatch::getContactId( $result->id );This must mean that this core function is returning a string rather than an integer.

Hope this help

ian

Yes that does the job, thanks.

BUT, back at the authentication plugin I think I've found a number of incompatibilities with v 3.0 that i didn't notice at first (and I think some of these may explain why not everyone has found valid logins blocked).

1) If there is no membership for a contact the plugin incorrectly allows a login.

This seems to be because of the code in civicrm.php at line 139:
138 // Make sure there is a membership record.
139 if ($membership['is_error'] == 1){
140 $response->status = JAUTHENTICATE_STATUS_FAILURE;
141 $response->error_message = 'no memberships for this contact';
142 ob_end_clean();
143 header($civicrm_redirect_old_membership);
144 exit;}
This no longer works because the action when a contact has no membership has been changed from raising an error code to setting the 'record_count' element of the membership array to 0 (api/v2/MembershipContact.php
 line 158):
 
155    if ( empty( $membershipValues ) ) {
156        # No results is NOT an error!
157        # return civicrm_create_error('No memberships for this contact.');
158        $membershipValues['record_count'] = $recordCount;
159        return $membershipValues;
160    }


A record_count of 0 is what line 139 of the the plugin now needs to test for (rather than the the 'is_error' element:
139 if ($membership['is_error'] == 1 || $membership['record_count']==0){


---

2)If a pay-later membership is taken out then a sign-in is allowed while the membership is still pending.
This is because of this code at line 158 in the plugin:
158 if ($membership_status['id'] <= $civicrm_is_current){
159 $response->status = JAUTHENTICATE_STATUS_SUCCESS;
160 $response->error_message = '';}
161 else {
162 $response->status = JAUTHENTICATE_STATUS_FAILURE;
163 $response->error_message = 'membership not valid';
164 ob_end_clean();
165 header($civicrm_redirect_old_membership);
166 exit;}
167 }
For a Paylater membership, the start, join and end dates are null until the membership is activated. The $membership_status['id'] is determined by the function "getMembershipStatusByDate" (CRM/Member/BAO/MembershipStatus.php, ), but this function can't set the 'id' element if all these dates are null. In line 158 above $membership_status['id'] is therefore empty and the logical test evaluates to true and so allows login.
To get around this, the section of code in the plugin needs to be preceded by something like
if(empty($membership_status['id'])) {
$membership_status['id']=9999;
}
which sets a large dummy value if none has already been set and so the login is prevented

3) The functions that return the membership status to the plugin ignore the manually set Membership Status
Theplugin ultimately gets the membership status from  "civicrm_membership_status_calc" which in turns calculates the status purely from the start, join and end dates using the function "getMembershipStatusByDate" (CRM/Member/BAO/MembershipStatus.php). (I'm guessing that this may previously have got its status value from the Status_id value in the civicrm_membership table - but I don't actually know).
getMembershipStatusByDate calculates the status from first principles using the membership status rules, and completely ignores the manual status setting for the membership. So you can cancel the membership, or mark it expired and it will still  report it as current unless the End date is also changed.
I think the plugin either needs to get its status from the civicrm_membership Status_id value, or else perhaps be conservative and block logins if either the manual status setting, or the getMembershipStatusByDate calculation suggests that the membership is not current.

As I say, my php skills ain't that great, so some of the stuff above may be wrong, but the plugin seems to work correctly after these changes.

Cheers

ian

I also had the problem with registered users not being able to login and the patch fixed that, but when a visitor has a failed login attempt (i.e. wrong un/pw), it still goes to a blank white page.  Does anyone else have this?

J1.5.14
CiviCRM 3.0.alpha1
Civiuser 0.4