Shield appears to be incompatible with Boost.

Boost creates cached HTML files, and then uses .htaccess rules to serve these files if they exist. Shield uses PHP to prompt the users for basic authentication.

Ideally, if Shield is enabled, Boost'd pages would also be protected behind an authentication prompt. The first time a page is visited by an anonymous user, they are prompted to login. However, after the page loads, Boost caches that page. When another user visits that page, before Shield can influence what happens, Boost has already delivered the cached page via the .htaccess rules.

At the very least, this should be documented, or set as a notice on the Status Report page.

Possible solutions:

1) Since Shield is often times used to protect a staging site before it's launched, disable Boost until launch, and disable Shield at launch. Easy, but annoying. Plus it makes it hard to test Boost before launch.

2) Don't protect with Shield any page that's cacheable by Boost. This doesn't accomplish my goal, though it is a truer representation of what happens with these two modules enabled.

3) Don't cache any page with Boost that's protected by Shield. Again, this still doesn't accomplish my goal, but it at least prevents Boost'd pages from being displayed to unauthenticated users. This can easily be done using a Boost hook:

/**
 * Implements hook_boost_is_cacheable().
 */
function shield_boost_is_cacheable($parts, $request_type = 'normal') {
  // If this page is protected by Shield, disable caching pages with Boost,
  // which would otherwise be accessible since Boost delivers pages before
  // Shield can influence authentication.
  if (shield_get_status()) {
    $parts['is_cacheable'] = FALSE;
    $parts['is_cacheable_reason'] = 'Shield prevents all pages from being cached by Boost.';
  }
  return $parts;
}

4) Configure basic authentication in .htaccess before Boost's rules. Thus, the Shield module wouldn't be needed. Or perhaps Shield could optionally work as a code generator, similar to how Boost works, creating the code to drop in to .htaccess that will enable basic authentication, so it happens on the Apache layer, not PHP.

Any other ideas for how to make these two excellent modules play well together?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joelstein’s picture

Status: Active » Needs review
FileSize
1.58 KB

Here's a patch which prevents Boost from caching any page that's shielded. It also shows a warning on the Status Report page.

geek-merlin’s picture

+++ b/shield.module
@@ -194,3 +194,17 @@ function shield_boot() {
+    $parts['is_cacheable_reason'] = 'Shield prevents all pages from being cached by Boost.';

This looks like it might be passed through t().

Otherwise this looks reasonable.

joelstein’s picture

Yeah, I just copied the way it was being used in boost.module, but we should probably wrap it in t(). Do I need to submit a new patch, or can you do that when you commit it?

Also, FWIW, I've been using this on dozens of sites, and it works perfectly, no problems.

geek-merlin’s picture

geek-merlin’s picture

I checked it and boost prints this string:

function boost_block_view_status() {
...
    $reason = ($_boost['is_cacheable_reason'] ? $_boost['is_cacheable_reason'] : 'reason unknown');
...
      '#markup' => '<p>' . t('This page will not be cached: %reason', array('%reason' => $reason)) . '</p>',

Boost
* does not use t() for $_boost['is_cacheable_reason'] (in about a dozen places)
* has no boost.api.php

Someone(tm) might file/find issues for this ;-)

I fixed it in this module's code though. Goes to dev today.

geek-merlin’s picture

Status: Needs review » Fixed
joelstein’s picture

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.