I'm not sure how to categorize this, or even if anything can be done about this, but I thought I would capture a note here in case this info is useful to others.

From what I can see, this module cannot be used along with many SSO modules, or really any module that needs to run drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) or drupal_bootstrap(DRUPAL_BOOTSTRAP_LANGUAGE) within its own hook_boot. This only applies to D7. The reason appears to be that the "double hijack" concept will prevent any logic that appears after drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) or drupal_bootstrap(DRUPAL_BOOTSTRAP_LANGUAGE) from running when one of these are called from inside any module's hook_boot.

Examples of modules that would need to do use drupal_bootstrap in this way within their own hook_boot include bakery, LDAP and crowd (the latter is one that I'm working on personally, and is how I noticed this). These modules use the following general pattern in a hook_boot:

// Run some checks to see if we should test the user for single-sign-on-access.
$should_run_sso_checks = some_logic_to_see_if_sso_check_needed();

if ($should_run_sso_checks) {
  // Do a full bootstrap as our checks for for single-sign-on-access require special Drupal includes or APIs
  drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
  // Run our special tests for single-sign-on-access and then probably reload the page so the user can be logged-in.
  run_sso_checks_and_refresh_page();
}

If dynamic cache is enabled, the part run_sso_checks_and_refresh_page() won't ever run. This will be true no matter what the $GLOBALS['conf']['cache'] value is.

Again, I'm really not sure what the solution would be... nor am I sure if there are be many users of SSO modules that also need dynamic_cache, but as it took me some time to figure this out I wanted to document it.

Comments

rjacobs’s picture

Of course one solution would be to set dynamic_cache as a dependency for any SSO module and then in hook_boot just do:

// Run some checks to see if we should test the user for single-sign-on-access.
$should_run_sso_checks = some_logic_to_see_if_sso_check_needed();

if ($should_run_sso_checks) {
  $GLOBALS['conf']['cache'];
}

And move run_sso_checks_and_refresh_page() into hook_init.

Still, any SSO modules that don't do this will continue to be broken by dynamic_cache, so it might be worth having this potential incompatibility documented somewhere.

rjacobs’s picture

Title: Dynamic cache incompatible with some SSO modules » Dynamic cache incompatible with some SSO-type modules
rjacobs’s picture

Issue summary: View changes

fix global var name