Fix leaky abstraction to respect hook_cas_user_alter() and allow user-sync.

Hi Brian,

Thanks for following up!

Because of this, cas_attributes can't be used by admin tasks or cron jobs that add/modify user accounts because cas_attributes will only ever work with user information for the currently authenticated user

How is this issue in particular solved? The CAS attributes are only populated on a user object when cas_login_check() is called, which calls cas_phpcas_attributes(). From what I can tell, attributes are not persisted to a user account from the CAS module. Any cron/admin task would need to invoke a user login programmatically to obtain the attributes again, right?

I have a custom user-sync module that populates user accounts from a external database and needs to populate the attributes ahead of time so that they are available for reference before the user actually logs in via CAS so that other users can assign them permissions, etc. My external database is the source for the CAS attributes and has the same values available. My cron-job code does the following, setting up the $edit['cas_user']['attributes'] array exactly like the CAS module does:

  ...
  
  // Build the cas_user object and allow modules to alter it.
  $cas_user = array(
    'name' => $webId,
    'login' => TRUE,
    'register' => variable_get('cas_user_register', TRUE),
    'attributes' => $attributes,
  );
  drupal_alter('cas_user', $cas_user);
  
  ...
  
  $account = cas_user_load_by_name($cas_name);
  // Automatic user registration.
  if (!$account && $cas_user['register']) {
    // No account could be found and auto registration is enabled, so attempt
    // to register a new user.
    $account = cas_user_register($cas_name);
    ...
  }
  
  // final check to make sure we have a good user
  if ($account && $account->uid > 0) {
    ...
     // Allow other modules to make their own custom changes.
    cas_user_module_invoke('presave', $edit, $account);
    ...
    if ($changed) {                                                                                                   
      $account = user_save($account, $edit);
    }

The cas_attributes_cas_user_presave(&$edit, $account) hook gets invoked by the cas_user_module_invoke('presave', $edit, $account); line above and this is where cas_attributes' direct usage of phpCAS calls makes for a leaky abstraction. Since there is no user authenticated via phpCAS when cron is running, cas_user_module_invoke('presave', $edit, $account); will fail without this patch, even though the data it needs is available to it in $edit array.

Since cas_attributes_cas_user_presave(&$edit, $account) only needs data that should be in the edit array due to injection by either the CAS module (in the normal login sequence) or by other modules (such as this sync sequence) there is no need for it to fetch the data from elsewhere.