2

We're using a Drupal module (CiviNorth) which hooks into Drupal's cron execution and updates civicrm's records' custom fields.

This has been failing due to the API calls not returning those custom fields.

Enabling the "CiviCRM: access all custom data" for anonymous users appears to make it work, but I'm hesitant to turn it on since I don't know if there's any security implications.

Note: We are not using ACLs in civi though we used to. All have been disabled for a while.

Why would the API return a result for an anonymous user but refuse to show custom fields specifically?

There may be more than one things going on here. I can't tell if this is a bug relating to ACLs or just general confusion with the code.

Can anyone recreate? Any Drupal cron job that fetches custom fields would do.

2 Answers 2

4

You need to turn on "Access all custom data" for anonymous users for a lot of very popular features (e.g. custom fields for anonymous users in profiles and webform_civicrm) to work. Someone else can contradict me, but I'm reasonably certain this has no impact on security unless a) anonymous users also have access to contact records, or b) you have custom field sets whose access should be restricted via ACL.

I'm sure there's a way to allow access to custom fields to anonymous users via ACL, but that often strikes me as overkill.

1
  • Thanks, John. That was kind of my feeling as well but I'm not 100% comfortable with just trusting that it's fine.
    – sdragnev
    Commented Jan 25, 2016 at 15:51
1

Drupal cron tasks run as the anonymous user per default. Generally the anonymous user won't have much in the way of CiviCRM permissions, so to execute CiviCRM tasks from within Drupal cron, you'll need to switch users in your module's hook_cron() method.

Here's Drupal's documentation on safely impersonating another user. If you swap in a $user object which has permission, your CiviCRM data access should function. Restore the default $user and session data when done to prevent unexpected consequences :)

For Drupal 7, and using user 1 as the user to run CiviCRM tasks as (you might prefer to use a dedicated CiviCRM cron user).

global $user;
$original_user = $user;
$old_state = drupal_save_session();
drupal_save_session(FALSE);
$user = user_load(1);

// Take your action here where you pretend to be the user with UID = 1 (typically the admin user on a site)
// If your code fails, it's not a problem because the session will not be saved
$user = $original_user;
drupal_save_session($old_state);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.