Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-25T15:51:10.627Z
Answers.Text: Thanks, John. That was kind of my feeling as well but I'm not 100% comfortable with just trusting that it's fine.
Answers.UserDisplayName: sdragnev
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-15T20:13:26.400Z
Answers.LastActivityDate: 2016-01-15T20:13:26.400Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>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 <code>hook_cron()</code> method.</p>
  
  <p>Here's <a href="https://www.drupal.org/node/218104" rel="nofollow">Drupal's documentation on safely impersonating another user</a>. If you swap in a <code>$user</code> object which has permission, your CiviCRM data access should function. Restore the default <code>$user</code> and session data when done to prevent unexpected consequences :)</p>
  
  <p>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).</p>
  
  <pre><code>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);
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-22T23:41:20.763Z
Answers.LastActivityDate: 2016-01-22T23:41:20.763Z
Answers.UserDisplayName: Chris Burgess
Body: <p>We're using a Drupal module (CiviNorth) which hooks into Drupal's cron execution and updates civicrm's records' custom fields.</p>
  
  <p>This has been failing due to the API calls not returning those custom fields.</p>
  
  <p>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.</p>
  
  <p>Note: We are not using ACLs in civi though we used to. All have been disabled for a while.</p>
  
  <p>Why would the API return a result for an anonymous user but refuse to show custom fields specifically?</p>
  
  <p>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.</p>
  
  <p>Can anyone recreate?
  Any Drupal cron job that fetches custom fields would do.</p>
  
Tags: <drupal><api><acl><cron>
Title: Drupal's cron job has no access to CiviCRM custom fields (Anon access to custom data?)
ThreadText: # Drupal's cron job has no access to CiviCRM custom fields (Anon access to custom data?)
  
  (Asked by: username_0 on 2016-01-15)
  
  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.
  
  **Tags:** drupal, api, acl, cron
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-01-15. Score: 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.
  
  > **Comments:**
  > **username_0**: Thanks, John. That was kind of my feeling as well but I'm not 100% comfortable with just trusting that it's fine.  
  
  ---
  
  ### Answer by username_2 on 2016-01-22. Score: 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);
  
  
  ---
  
  